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Abstract 

The  design  of  large,  complex  digital  circuitry  requires  highly  skilled  engineers.  Much 
of  the  time  spent  by  theiJe  engineers  in  the  design  phase  involves  tasks  that  are  repetitive, 
tedious,  and  slow.  If  these  repetitive  tasks  are  automated,  the  engineer  can  spend  more 
time  managing  the  design  process  and  produce  a  better-quality  design  in  less  time.  Logic 
programming  can  be  used  to  automate  design  tasks,  even  those  that  require  a  high  de¬ 
gree  of  skill.  This  thesis  investigates  several  aspects  of  the  digital  circuit  design  process 
that  involve  pattern  matching  paradigms  suitable  for  encoding  in  the  logic  programming 
language  Prolog. 


Logic  Programming  in  Digital  Circuit  Design 


/.  Introduction 


1.1  Background 

Several  Computer  Aided  Design  (CAD)  systems  are  used  at  the  Air  Force  Institute 
of  Technology  (AFIT)  to  design  electronic  circuits.  These  C.AD  systems  function  with 
conventional  software  and  work  much  like  a  hammer  or  screwdriver  in  that  the  quality  of 
the  final  product  is  a  direct  function  of  the  ..kill  of  the  crafts.man.  Computers  run  with 
conventional  CAD  software  lack  the  inference  ability  associated  with  computers  which 
use  artificial  intelligence  (AI)  languages.  When  pattern-matching  AI  languages  are  used 
instead  of  conventional  CAD  software,  computers  can  draw  “intelligent”  conclusions  con¬ 
cerning  electronic  circuit  structure  from  simple  facts.  Computers  using  AI  software  can  be 
useful  in  discovering  design  mistakes  before  they  become  a  problem  [46]. 

AFIT  currently  supports  research  which  relies  heavily  on  conventional  CAD  systems. 
As  technology  progresses  and  electronic  circuit  design  becomes  increasingly  comple.x.  the 
opportunity  for  making  a  design  error  increases  significantly.  Mistakes  in  circuit  design  are 
always  costly  to  correct  unless  they  are  discovered  in  an  early  phase  of  the  design  process. 
Design  errors  can  be  found  and  corrected  before  they  become  a  serious  problem  if  C.AD 
systems  are  used  which  incorporate  logic  programming  and  knowledge -based  reasoning. 

The  special  character  of  logic  programming  with  an  AI  language  such  as  Prolog  can 
be  e.xploited  to  automatically  design  electronic  circuits  through  knowledge-based  reasoning 
[14:59].  Employing  knowledge-based  reasoning  in  the  circuit  design  process  can  be  useful  in 
ensuring  the  functional  correctness  of  a  particular  specification,  especially  when  the  design 
involves  tedious  tasks  that  are  prone  to  human  error  [5:100|. 

l.S  Statement  Of  The  Problem 

Logic  programming  can  be  used  in  the  design  process  during  any  phase  which  is  de¬ 
pendent  on  pattern-matching.  Circuit  modelling,  simulation,  and  transformation  are  some 

of  the  processes  whose  outcomes  depend  on  the  ability  of  the  design  engineer  to  detect 
« 

recurring  patterns.  The  pattern-matching  ability  of  Prolog  can  be  used  to  automate  these 
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design  processes,  producing  quicker,  more  accurate,  and  more  consistent  results.  Prolog's 
built-in  depth-first  search  strategy  guarantees  that  all  possible  solutions  to  a  problem  will 
be  found.  This  thoroughness  can  be  used  during  many  phases  of  the  engineering  process 
to  ensure  that  the  best  solution  to  a  given  problem  is  found.  This  thesis  investigates  appli¬ 
cations  of  logic  programming  in  digital  circuit  modelling,  simulation,  and  transformation. 

1.3  Assumptions 

The  reader  should  have  a  basic  understanding  of  logic  programming  with  Prolog.  If 
that  is  not  the  case,  a  good  source  for  reference  would  be  either  Programming  in  Prolog 
[16]  by  VV.F.Clocksin  and  C.  Mellish  or  Prolog  Programming  jo.  Artificial  Intelligence  [4] 
by  Ivan  Bratko.  Several  outstanding  articles  on  the  subject  are  also  available  for  reference 
[l,  2,  3,  15,  17,  18,  19,  20,  24,  28,  35,  37,  38,  40,  47).  Chapter  2  contains  an  introduction  to 
some  of  the  more  important  aspects  of  logic  programming  which  are  central  to  this  thesis. 
Chapter  2  is  not  intended  to  be  a  tutorial  or  e.xtensive,  all-encompassing  discussion,  but 
rather  a  beacon  for  the  less  informed  reader  to  follow. 

l.y,  Scope 

This  thesis  will  focus  on  several  issues  associated  with  digital  circuit  design  and  ways 
in  which  logic  programming  can  be  exploited  to  automate  ci.’‘cuit-design  processes.  A  brief 
outline  of  logic  programming  with  Prolog  is  presented.  Aspects  of  Prolog  which  are  central 
to  the  thesis  are  explained.  Logic  programming  in  general  and  the  pattern-matching  ability 
of  Prolog  in  particular  are  used  to  develop  algorithms  which  can  be  used  to  assist  digital 
circuit  design  engineers  by  automating  selected  segments  of  the  design  process.  Digital 
circuit  modelling,  simulation,  and  some  aspects  of  circuit  transformation  are  discussed. 

1 . 0  .4  pproach/ Methodology 

.4fter  a  brief  explanation  of  some  of  the  features  of  Prolog  used  in  this  thesis,  method.'^ 
of  digital  circuit  modelling  with  Prolog  are  investigated.  Following  the  development  of  a 
modelling  protocol,  a  simple  transformation  process,  extraction,  is  presented.  Extraction 
uses  the  pattern-matching  capabilities  of  Prolog  to  detect  recurring  patterns  in  digital  cii- 
cuits.  Several  examples  are  shown.  Circuit  simulation  is  also  discussed.  Several  important 
traits  of  Prolog  make  this  language  an  ideal  one  for  simulating  digital  circuit  operation. 
Finally,  another  transformation  process,  called  specialization,  is  developed.  Specialization 


1-2 


can  be  used  to  eliminate  one  class  of  redundant  components  from  a  circuit,  resulting  in  a 
more  economical  design. 

1.6  Overview 

The  present  chapter  introduces  applications  of  logic  programming  to  digital  circuit 
design.  The  concepts  of  modelling,  simulation,  and  transformation  are  mentioned  and  the 
objectives  of  this  research  along  with  an  overall  view  of  assumptions  and  methodologies 
are  stated. 

Chapter  2  presents  a  brief  history  of  logic  programming  together  with  a  superficial 
introduction  to  Prolog.  The  main  focus  of  this  chapter  is  on  Prolog  and  aspects  of  the 
language  which  can  be  exploited  to  aid  in  the  design  of  digital  circuitry.  Chapter  2  is  based 
on  an  e.xtensive  review  of  current  as  well  as  past  literature  on  the  subject. 

Chapter  3  addresses  the  use  of  Prolog  in  modelling  digital  circuits.  It  shows  how 
different  paradigms  are  used  in  digital  circuit  modelling.  Several  examples  illustrate  the 
different  methodologies. 

Chapter  4  discusses  in  detail  one  aspect  of  circuit  transformation,  extraction.  A 
simple  extraction  algorithm  is  developed  and  applied  to  a  circuit  composed  of  N.A.ND- 
gates.  The  circuit  is  tested  and  all  full-adder  combinations  are  extracted. 

Chapter  5  discusses  the  application  of  Prolog  to  the  simulation  of  digital  combina¬ 
tional  and  sequential  circuits.  .A.lgorithms,  along  with  sample  simulations,  are  presented. 
A  digital  circuit  simulator  that  operates  with  a  subset  of  the  7400  series  of  TTL  integrated 
circuits  is  presented  at  the  end  of  the  chapter.  The  simulator  is  easy  to  use  and  operates 
much  faster  than  simulators  previously  developed  at  .AFIT. 

Chapter  6  highlights  another  transformation  problem,  that  of  attempting  to  achieve 
a  more  efficient  design  by  identifying  and  eliminating  unused  components.  The  proce.ss. 
called  specialization,  eliminates  all  components  that  have  unused  outputs  from  a  circuit 
and  automatically  rewrites  the  modified  circuit  and  its  connections. 

The  final  chapter,  Chapter  7,  discusses  the  strengths  and  weaknesses  of  the  algoritlim.-^ 
presented  and  makes  recommendations  for  the  direction  of  future  research. 

Throughout  this  thesis,  the  following  convention  for  describing  logic  components  will 
be  adopted: 
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II.  An  Overview  of  Logic  Programming 


2.1  Some  Important  Developments  in  the  History  of  Automated  Reasoning 

2.1..  Early  Developments.  Automated  reasoning  is  based  on  the  theory  of  predi¬ 
cate  calculus.  Predicate  calculus  was  invented  in  1879  by  Gottlob  Frege,  a  mathematician 
[42:107],  Frege's  goal  was  to  develop  a  system  that  could  be  used  to  analyze  the  formal 
structure  of  pure  thought.  He  called  his  system  Degriffsschrift  which  loosely  translates  to 
“notation  for  concepts”.  Frege  envisioned  his  system  as  a  universal  language  that  could 
be  used  to  represent  every  form  of  rational  thought.  The  represented  thoughts  could  be 
manipulated  in  a  precise  and  mathematical  way  in  order  to  deductively  reason  about  them. 
Frege  accepted  that  his  system  was  complete.  Formal  proof  of  the  completeness  of  Frege's 
system  of  predicate  calculus  did  not  come,  however,  until  1929  and  19.30  wheii  Thoralf 
Skolem,  Kurt  Godel  and  Jacques  Herbrand  proved  independently  that  Frege's  system  was 
a  complete  system  of  notation  (42:108).  Herbrand  had  several  versions  of  the  proof  pro¬ 
cedure;  one  version  used  the  process  of  unification  which  later  played  a  major  role  in  the 
development  of  logic  programming. 

Another  important  theoretical  contribution  to  automated  reasoning  came  in  1936 
when  A.M.  Turing  showed  that  it  weis  possible  to  invent  a  machine  that  could  be  used  to 
compute  any  sequence  of  numbers  that  were  calculable  by  finite  means.  He  also  showed 
that  *’is  “automatic  machine”  could  find  all  provable  formulae  of  the  predicate  calculus 
provided  the  notation  was  systematic  and  involved  a  finite  number  of  symbols  [48:252]. 

The  role  of  logic  in  the  early  development  of  the  field  of  artificial  intelligence  was  lim¬ 
ited  to  meta-level  reasoning  about  program  correctness  and  attempts  to  automate  theorem 
proving.  In  1955,  Evert  Beth  made  the  first  attempt  at  programming  predicate  calculus 
proofs  on  a  computer.  The  process  was  computationally  intensive  and  only  small  proofs 
could  be  done  [42:108].  A  major  breakthrough  came  in  1965  when  J.A.  Robinson  published 
his  resolution  principle. 

Resolution.  Resolution  was  a  major  step  forward  in  the  field  of  automated  theorem 
proving  as  well  as  logic  programming  and  is  one  of  the  most  powerful  theorem  proving 
techniaues  currently  in  use.  It  uses  Herbrand's  process  of  unification,  a  generalized  form  of 
pattern  matching  [11:70-97].  The  resolution  process  creates  the  least  specialized  or  most 
general  common  expression  from  two  atomic  relations  by  substituting  for  like  variables  in 
both  of  them  [24:2].  The  resolution  process  is  applied  to  problem  statements  written  in 
clause  form.  .A.  logic  clause  is  an  expression  of  the  form 
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htad 


{m,n  >  0) 


' - - - ' 

6o(fy 

where  atoms  Bi,..  .,Bm  constitute  the  head  and  represent  zero  or  more  conclusions.  The 
body  is  made  up  of  goals  .4i, .  ..,A„  and  represent  zero  or  more  conditions  [44:309].  If  the 
clause  contains  the  variables  Xi,...,Xn  it  can  be  read  as 
for  all  Xi,. .  .,xi: 
if  Ai  and . .  .and  A„  then 
Bi  or ...  or  Bm- 

If  n  =  0,  then  the  clause  is  interpreted  as 
for  all  a:i, . . . , lit 
Bi  or . .  .or  Bm- 

If  m  =  0  then  the  clause  is  interpreted  as 
for  no  ii, . . . 

Ai  and  . . .and  A„. 

If  m  =  n  =  0  then  the  clause  is  interpreted  always  to  be  false  [36:426].  The  basic  prin¬ 
ciples  of  the  resolution  process  can  be  illustrated  in  a  simple  way  within  the  confines  of 
propositional  logic.  Consider  the  two  expressions 
clause  1.  Ll  V  T2  V  ~  13 
clause  2.  L4  V  Lb  V  Z,3 

where  the  Ls  are  arbitrary  literals  and  ~  represents  the  negation  of  a  literal.  Clauses  are 
expressed  as  the  disjunction  (v)  of  literals.  The  literals  are  expressed  as  conjunctions  of 
indivisible  atoms.  An  atom  is  opposed  if  il  ai.>peci.ib  directly  in  one  clause  and  negated  in 
another  [8:7].  In  the  two  expressions  given  above.  L3  is  opposed.  The  resolvent  of  the 
two  expressions  can  be  generated  as  follows: 

1.  Form  an  expression  that  contains  all  literals  of  the  two  parent  expressions. 

2.  Delete  the  opposed  pair  of  literals. 

3.  Delete  any  repeated  literals. 

Thus  the  resolvent  of  the  example  expression  is 

LI  V  T2  V  [A  V  Lb. 

The  resolvent  expression  generated  from  the  two  parent  expressions  are  a  logical  conse¬ 
quence  of  the  parent  expressions.  A  given  set  of  expressions  will  produce  nothing  but 


legally-inferred  logical  consequences  when  subjected  to  the  resolution  process.  The  au¬ 
tomation  of  this  process  resulted  in  the  development  of  the  logic  programming  language 
Prolog. 

2. 1.2  The  Emergence  of  Prolog.  The  origin  of  Prolog  can  be  viewed  as  the  conflu¬ 
ence  of  two  different  endeavors;  Alain  Colmerauer's  interest  in  natural  language  processing, 
and  Robert  Kowalski's  research  into  logic  and  theorem  proving  [18:26].  Their  independent 
efforts  resulted  in  the  development  of  the  first  efficient  programming  language  based  on 
Frege's  system  of  logic  [47:96].  Prolog,  short  for  Programmation  en  Logique  [.37:38]  is  based 
on  a  restricted  form  of  automated  reasoning  in  which  logic  clauses  have  no  more  than  one 
conclusion  associated  with  a  set  of  conditions  [42:111].  Prolog  programming  involves  e.K- 
pressing  information  in  Horn-clause  form  (discussed  in  section  2.2.1)  and,  using  Robinson's 
resolution  process,  forming  new  deductions  by  reasoning  about  the  logical  content  of  the 
information.  .A  Prolog  interpreter  can  be  thought  of  as  a  resolution  based  theorem-prover. 
Clocksin  and  Mellish  [16]  describe  programming  in  Prolog  as: 

1.  Declaring  some  facts  about  objects  and  their  relationships; 

2.  Defining  rules  about  objects  and  their  relationships,  and 

3.  Asking  questions  (queries)  about  objects  and  their  relationships. 


2.2  Prolog:  ,4  Logic  Programming  Language 

2.2.1  Hom-Clauses.  Logic  Programming  is  a  restricted  form  of  autom-ited  reason¬ 
ing  based  on  the  use  of  Ilorn-clauses.  Horn-clauses  are  logic  clauses  in  which  no  more 
than  one  conclusion  is  associated  with  a  set  of  conditions.  Horn-clause  structure  can  be 
expressed  as  any  of  the  forms  found  in  Table  2.1. 


Table  2.1.  Horn-clause  forms 


Horn-Clause  Form 

Prolog  Function 

Bx  — 

fact 

Bx 

rule 

^  A,,...,/!,. 

query 

Horn-clause  syntax  allows  the  conjunction  of  zero  or  more  conditions  (also  known 
as  antecedents)  in  the  clause’s  body  to  imply  at  most  one  conclusion  (also  known  as  a 
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consequent)  in  the  clause’s  head  [7j.  A  Horn-clause  states  that  for  all  the  possible  values  of 
the  variables  appe<aring  in  the  clause,  if  all  the  '■onditions  of  the  conclusions  hold,  then  the 
conclusion  is  true.  Every  variable  is  understood  to  be  universally  quantified  over  the  clause 
in  which  it  appears;  hence  each  clause  stands  alone.  Horn-clauses  can  be  thought  of  as 
procedural  definitions.  The  head  of  the  clause,  accompanied  with  corresponding  arguments 
(e.xplained  in  more  detail  later),  represents  the  procedure’s  name.  The  conditions  of  tin-; 
clause,  accompanied  with  their  corresponding  arguments,  represent  the  procedure’s  body. 
All  clauses  with  the  same  head/argument  structure  are  collectively  called  a  procedure.  .-Vs 
shown  in  Table  2.1,  Prolog  clauses  occur  in  three  forms:  facts,  rules,  and  queries. 

Facts.  A  fact  is  the  most  basic  statement  in  Prolog.  Facts  are  conclusions  or 
consequents  that  have  no  conditions  or  antecedents;  facts  thus  form  simple  statements 
about  o'ojects  and  their  relationships.  A  fact  announces  that  some  relation  is  true.  .\ 
finite  set  of  facts  constitutes  a  simple  logic  program.  S^me  e.xamples  of  facts  are  shown  in 
Table  2.2. 


Table  2.2.  E.xamples  of  Prolog  facts 

Prolog  Fact  Mefming 

likes (joe, apples) .  "joe  likes  apples." 

friendCbonny , joe) .  "bonny  is  a  friend  of  joe." 
motherCsally ,sue) .  "sally  is  the  mother  of  sue." 


Rules.  A  single  program-clause  can  either  be  a  fact  or  a  rule.  R,ules  define  compli¬ 
cated  relationships  among  objects  by  announcing  that  the  head  of  the  rule  is  true  if  all  of 
the  goals  in  the  body  of  the  ruie  are  true.  A  rule  has  the  form 


:  -  .4., 


(n  >  0) 


which  is  the  same  form  as  that  given  earlier  in  Table  2.1  for  Horn-clause  rules.  .\ote  that  a 
fact  is  a  special  form  of  a  rule  when  n  =  0.  The  syn  aX  is  used  in  Prolog  programming 
to  replace  the  - —  and  can  be  read  iis  the  word  ‘‘if’  or  "is  implied  by”  (.34:14.51.  Some 
e,xamples  of  rules  are 


Rule 


Meaning 


happy (X) 
has(X,Y), 
dog(Y) . 


"Any  X  is  happy  if 
X  y  s  any  Y  eind 

Y  ■  M  •• 

t  v»  ^  * 


likes (X,Y)  ».\y  .■  -.s  any  Y  if 

friends  (.X  ,2)  ,  i.:  friend  of  any  2  and 

likes(2,Y).  2  1  .-ces  Y." 

Prolog  programs  are  composed  of  facts  art'  >  les.  Facts  are  stored  with  rules.  .‘V 
collection  of  facts  and  rules  is  commonly  refer:,  d  '  aS  a  dotabase.  There  ia  uo  need  in 
Prolog  programming  to  differentiate  oetween  pro{.-ams  and  data. 

Queries.  Queries  provide  a  means  ^  r  retrieving  information  from  a  logic  program. 
.4  query  has  the  special  form 


?-G„. 

..4  query  initiates  the  execution  of  a  program  and  is  typically  typed  at  the  terminal  with 
the  interpreter  running  and  the  desired  program  loaded.  Prolog  solves  a  q;.‘ery  by  forming 
a  set  of  variable  bindings  that  makes  each  of  the  goals  in  the  query  consistent  with  the 
facts  and  rules  in  the  program.  This  process  can  be  illustrated  with  the  following  example: 


fact  1. 

likist joe, apples) . 

fact  2. 

friendCbonny, joe) . 

rule  1. 

likes(X,Y) 

friend(X,2) , 
likes(2,Y) . 

The  interpreter  now  knows  two  facts  that  state  that  joe  iikes  apples  and  bonny  i.s  a  friend 
of  joe.  The  single  rule  expresses  a  more  complex  relationship.  Any  X  likes  any  Y  if  X  is 
a  friend  of  2  and  2  likes  Y.  The  database,  once  loaded,  can  be  interrogated  with  queries. 
Consider  the  following  query 

?“  iikes(joe,X) . 

The  Prolog  interpreter  will  start  at  the  top  of  the  database  and  search  for  a  fact  or  rule 
whose  head  matches  our  query.  The  interpreter  knows  it  is  looking  for  facts  or  rules  named 
likes  with  two  arguments,  the  first  of  which  mu.>t  be  “joe"  or  able  to  be  instantiated  to 


“joe”.  The  second  variable  X  has  not  yet  been  instantiated.  The  first  fact  encountered 
that  meefs  all  the  requircinents  is  fact  1  if  X  is  instantiated  to  “apples”.  The  interpreter 
(assuming  Prolog- 1  is  being  used)  will  respond  to  our  query  with 

X  =  apples 
more  (y/n)?  y 
no 

The  interpreter  can  not  find  any  more  facts  c-  rules  that  it  can  match  with  our  query. 

.4s  a  ..lore  comple.'c  e.'cample,  ~.o'  sider  the  compound  query 

?-likes(joe,X) .likes (bonny, X) . 

This  query  asks  tlie  interpreter  to  find  some  instantiation  for  the  variable  X  that  both  “Joe" 
and  “bonny”  like.  The  following  sequeiue  of  events  will  occur: 

1.  The  first  goal  of  the  query  succeeds  b.ecause  of  fact  number  1  with  X  instantiated  to 
“apples”. 

-  2.  “bonny”  can  not  be  matched  to  any  likes  fact  so  the  second  goal  can  only  succeed 
through  rule  1.  The  rule  is  invoked  with  X  instantiated  to  “bonny”  and  the  variable 
Y  instantiated  to  “apples”. 

.3.  The  first  goal  of  rule  I  succeeds  with  X  instantiated  to  “bonny”  and  Z  instanti.-u'.' 
to  “joe”  via  fact  2. 

4.  The  second  goal  of  rule  1  then  succeeds  v/iih  Z  instantiated  to  “joe”  and  Y  to  "apples" 
using  iact  1  again. 

•5.  Sine  both  goals  of  the  queiy  goal  succeeded,  the  query  itself  succeeds  with  X  instan¬ 
tiated  to  “apples”. 


The  interpreter’s  response  to  our  query  would  then  be 

X  =  apples 
more  (y/n)?  y 
no 
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Programming  in  Prolog.  There  are  at  least  three  styles  of  programming  lan¬ 
guages:  procedural,  functional,  and  relational  (20). 

1.  Procedural  -  In  a  procedural  language,  the  steps  that  will  eventually  produce  the 
desired  result  are  explicitly  specified.  The  programmer  must  specify,  step  by  stop, 
how  something  is  to  be  done.  The  e.xecution  of  a  procedural  program  is  understood 
by  tracing  through  each  step  of  the  p’-ocess. 

2.  Functional  -  In  a  functional  language,  i.  «thods  for  calculating  values  are  defined. 
Operationally,  expressions  are  evaluated  until  the  final  value  is  determined. 

.3.  Relational  -  .-V  relational  language,  also  known  as  a  logic  programming  language, 
specifies  relations  among  values.  A  logic  program  can  be  vie\.ed  as  a  collection  of 
relations  with  each  clause  specifying  some  condition  under  which  the  relation  holds. 
Logic  programming  is  declarative:  the  programmer  specifies  “what"’  is  to  be  done, 
leaving  the  "how”  largely  up  to  the  computer. 

Prolog  programming  uses  relatic.if  within  a  logical  structure  to  represent  knowledge. 
Deductions,  based  on  the  represented  kuovv.odge,  are  used  to  form  logical  consequences. 
Prolog  programming  allows  knowledge  »o  be  viewed  both  procedurally  and  declarativelv. 
The  procedural  aspect  of  knowledge  representation  is  found  in  the  order  of  execution 
of  the  program  statements.  The  declarative  aspect  is  embodied  in  the  logic  statements 
that  describe  the  problem  domain  and  how  to  solve  problems  .n  vhat  domain.  The  logic 
programmer  is  less  concerned  with  how  the  machine  will  solve  a  particular  problem  and 
more  concerned  with  the  accuracy  of  the  defined  relationships  of  the  problem  and  how  they 
interact  and  hold  under  various  circumstances.  Ideally,  the  Prolog  interpreter  takes  care 
of  the  “how”  aspect  of  problem  solving,  freeing  the  programr,  "r  to  focus  on  the  relations 
characterizing  a  problem  (4.5:49). 

2.2.2. J  Prolog  Syntax.  Prolog  uses  only  one  data-type.  the  term  (7).  .Any 
term  has  one  of  three  forms: 

1,  a  constant, 

2.  a  variable,  or 

3  a  structure. 

A  constant  is  either  an  atom  or  a  nuinber.  .\n  atom  can  be  represented  either  by  a 
.sequence  of  alphanumeric  characters  beginning  with  a  lower-case  letter  or  by  a  sequence 
of  characters  enclosed  in  single  quotes.  .\  variable  in  Prolog  stands  for  some  definite 
but  unidentified  object.  A  variable  is  expreb.>cd  by  a  sequence  of  alphanumeric  characters 
or  underscores,  beginning  vith  either  an  upper  case  letter  or  an  underscore.  Variables  m 


Table  2.3.  Prolog  terms 


Constants 

Variables 

a 

A 

ab 

Ab 

a.b 

AJB 

'AB’ 

JtB5 

1 

.1 

Prolog  do  not  designate  storage-locations  in  memory  as  do  variables  used  in  conventional 
languages.  Instead,  variables  are  used  for  pattern-matching  within  a  term.  Table  2.3  gives 
some  e.xamples  of  simple  terms. 

.\  compound  term  is  composed  of  a  functor  and  a  sequence  of  one  or  more  arguments 
and  is  commonly  referred  to  as  a  structure.  .A.  structure  has  the  form 

arguments 

Junctor 

where  foo,  the  functor  (or  predicate),  is  an  atom  and  ii, . . . ,  the  arguments,  are  terms. 
The  number  of  arguments  is  referred  to  as  the  arity  of  the  term.  The  Prolog  interpreter 
distinguishes  among  the  different  forms  of  structures  by  the  name  of  the  functor  and  its 
arity.  A  constant  is  considered  to  have  an  arity  of  zero.  Table  2.*!  gives  some  e.xamples  of 
structures. 


Table  2.4.  E.\amples  of  Prolog  structures 


Prolog  Structure 

Functor 

Arity 

student(name(first(tom))) . 

student 

1 

likes (joe, bonny) 

likes 

2 

family(dad(joe) ,mora(bonny) ,children(jill , Joshua) ) 

family 

3 

Lists.  .An  important  data  structure  used  in  logic  programming  is  the  list.  .A  ii.sl 
is  a  sequence  of  any  number  of  terms  such  as  6,  bob,  (fred(man),sally(woman)).  and  four. 
Written  in  Prolog,  this  list  would  appear  as 

(6.bob.(fred(man),sally(woman)j,four). 


A  list  is  e.xpressed  with  the  following  format : 


where  the  head  of  a  list  is  the  first  term  (or  element)  in  the  list.  The  head  of  the  list  in 
the  above  e.xample  is  the  element  “1”.  The  tail  of  a  list  is  itself  a  list  that  consists  of 
everything  in  the  original  list  except  the  head.  The  tail  of  the  above  e.xample  is  the  list 
[2,3].  Square  brackets  “[  |”  are  used  to  denote  an  empty  list.  Throughout  this  thesis  a  list 
will  be  typically  represented  as  [X|Y]  where  X  denotes  the  head  and  Y  denotes  the  tail.  The 
list  [1,2,3],  written  in  this  form  would  be  [l,][2,3]].  Sometimes  it  is  convenient  to  denote 
more  than  one  element  at  the  front  of  a  list.  To  show  this,  the  representation  is  [X,Y,ZiY] 
where  X,  Y,  and  Z  are  the  first  three  elements  of  the  list  and  Y  is  the  tail.  The  list  [1,2,3], 
written  in  this  form  would  be  [1,2,3|[)]. 

2.2.2. 2  Prolog’s  Search  Strategy,  k  useful  concept  in  the  field  of  artificial 
intelligence  is  the  search-tree  [45:50].  A  search-tree  is  a  mapping  onto  a  tree-structure  of  a 
search-process.  It  is  instructive  to  study  the  search-tree  produced  by  the  Prolog  interpreter 
in  the  e.xecution  of  a  problem.  Consider  the  following  program  of  simple  facts. 

a(l) . 
a(2) . 
a(3). 
b(0). 
b(2). 
b(3). 

and  the  following  query  input  at  the  screen  prompt: 

?-  a(X),b(X). 

The  query  literally  translates  to  “find  some  instantiation  for  the  variable  X  such  th.at  a(X) 
and  b(X)  are  true”.  This  problem  ha.s  two  solutions,  X  =  2  and  X  =  3.  k  graphical 
representation  of  the  search-tree  for  this  problem  is  found  in  Figure  2.1.  Prolog's  built-in 
.search  mechanism  is  depth-first,  meaning  that  it  will  start  at  the  leftmost  branch  of  th*: 
search  tree,  following  it  to  the  bottom  before  trying  a  new  branch.  This  is  because  the 
interpreter  scans  the  database  from  top  to  bottom  in  an  attempt  to  satisfy  the  querv.  In 
the  e:\ample,  the  interpreter  is  initially  interested  in  finding  a  fact  with  the  functor  ".t". 
as  a(X)  is  the  first  goal  of  the  query.  The  first  “a’  fact  encountered  in  the  search  is  a(l); 


a(X).b(X). 


Figure  2.1.  .\  search-tree. 


therefore  X  is  instantiated  o  the  value  of  1  and  the  second  goal  of  the  query  becomes  b(  1) . 
The  interpreter  unsuccessfully  looks  at  b(0),  b(2),  and  b(3)  before  discarding  a(l)  as 
a  possibility.  The  interpreter  now  drops  down  to  the  ne.Kt  “a”  fact  which  is  a(2).  The 
interpreter  picks  up  a(2)  as  a  possibility  for  satisfying  the  query  with  X  instantiated  to 
“2”.  It  then  looks  at  b(0)  and  finding  no  match  proceeds  to  b(2)  where  a  successful 
match  is  found.  .-Vt  this  point  tlie  match  i.s  reported  to  the  screen  and  the  user  as.ked  if 
more  solutions  are  desired.  Typing  "no"  at  the  screen  prompt  will  terminate  the  search. 
Typing  "yes"  will  cause  the  search  to  continue  from  the  point  where  the  interpreter  left 
oft.  Since  a(2)  can  not  be  matched  with  b(3),  a(2)  is  discarded  and  a(3)  is  picked  up. 
The  interpreter  tries  to  match  a(3)  with  b(0)  and  b(2)  before  finding  a  match  with  bC3). 
This  second  match  is  reported  to  the  screen  a.s  X  =  3  and  at  this  point,  the  database  ha.-, 
been  searched  e.xhaustively  and  no  more  matches  e.xist.  The  search-tree  of  Figure  2.1  has 
been  completely  traversed  from  top  to  bottom,  left  to  right. 

2. 2.2.3  Control  of  Program  Execution.  A  conventional  algorithm  written  in 
either  a  procedural  or  functional  language  is  thought  to  be  described  as: 

program  =  description  of  (logic  -f  control) 


with  the  logic  component  describing  the  domain-specific  part  of  the  algorithm  and  the 
control  part  involving  the  solution  strategy  [36:-l29|.  Algorithms  written  in  a  procedural 
or  functional  language  must  specify  both  the  logic  and  the  control  components:  they  are 
intermirced  inseparably  in  the  code  (33:99).  Algorithms  written  in  a  relational  language 
need  only  specify  the  logic  component  of  the  problem  unless,  for  reasons  discussed  later, 
it  is  advantageous  for  the  programmer  to  modify  the  control  component. 

Prolog  only  requires  the  user  to  provide  facts  and  rules  describing  relations  that  are 
pertinent  to  the  problem  domain.  Control,  often  viewed  as  the  "how"  of  the  problem, 
is  ideally  left  up  to  the  machine.  In  logic  programming,  control  and  logic  are  separate 
components  of  a  program  and  may  be  specified  separately.  .An  algorithm  written  in  a  logic 
programming  language  can  be  described  as  [36j: 

algorithm  =  logic  -f  control 

where  the  logic  and  the  control  components  can  be  disjoint.  The  order  of  appearance  of 
the  clauses  in  a  logic  program  should  have  no  logical  (declarative)  significance  because  cacli 
clause  states  some  property  of  the  predicate  independently.  This  holds  true  for  Prolog  as 
long  as  control  of  program  e.xecution  is  left  entirely  up  to  the  interpreter. 

Unmodified  Control.  .As  an  c.xample  of  a  problem  that  can  be  solved  by  allow,  ing 
the  Prolog  interpreter  to  have  full  control,  consider  the  task  of  determining  whether  an 
clement  is  a  member  of  a  list.  .Any  element  X  is  a  member  of  a  list  if 

either  (i):  X  is  the  head  of  the  list 

or  (2):  X  is  a  aeaber  of  the  tail  of  the  list. 

These  re’ations  are  described  in  Prolog  synia.':  as  follows: 

rule  i .  netiberCX ,  (X 1  Rest]  )  . 

rule  2.  TietsberCX,  CYlRcstj)  :  = 
netiberfX.Rest) . 

The  name  of  this  procedure  is  nsenber.  The  first  Ilorn-clau.se  stales  that  the  element  X 
is  a  member  of  any  list  that  has  X  as  its  head  and  Rest  as  its  tail.  If  the  element  X  i:. 
the  clement  we  arc  searching  for  and  it  orcisr.^  at  the  head  of  the  list  then  membership  is 
determined  and  true  is  returned  to  the  invoking  call.  If  the  element  X  is  not  the  f  ea«l  of 
the  list,  the  first  clause  fails  and  the  second  clause  is  invoked.  The  second  clause  slates 
the  second  condition  for  membership:  that  i.s.  the  elenicnl  X  is  a  member  of  a  list  with  an 
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element  Y  as  its  head  and  Rest  as  its  tail  if  the  element  X  is  a  member  of  Rest.  The  logic  of 
determining  membership  is  completely  specified  while  the  control  aspect  is  left  completelv 
unspecified,  leaving  the  interpreter  to  solve  any  queries  regarding  member  as  it  pleases. 
Note  that  rule  1  could  be  switched  with  rule  2  and  only  the  efficiency  of  the  e.xecution  of 
the  procedure  would  be  affected. 

Modified  Control.  Sometimes  it  can  be  advantageous  to  modify  the  control  com¬ 
ponent  in  a  logic  program.  Modification  is  usually  done  to  improve  the  efficiency  of  the 
algorithm.  Efficiency  can  be  enhanced  by  using  a  special  term  in  Prolog  called  the  ’‘cut.'’ 
represented  by  the  symbol  “!”.  A  cut  allows  succeeds  as  a  goal  and  allows  a  programmer 
some  control  over  the  search  mechanism  by  limiting  the  interpreter's  access  to  specified 
branches  of  the  search  tree.  The  effect  of  the  cut  limits  the  number  of  solutions  to  the  first 
one  found,  once  the  cut  has  been  encountered.  Consider  this  modification  to  a  previous 
example. 

a(l). 

a(2)  !. 

a(3). 

b(0). 

b(l). 

b(2). 

b(3). 

If  the  database  is  queried  with  the  same  query  as  was  used  previously  (?-  a(X)  ,b(X) . ). 
the  interpreter  will  proceed  down  the  new  search-tree,  finding  the  first  match  between 
a(l)  and  b(l).  Proceeding  on,  the  interpreter  picks  up  a(2)  and  encountc  the  cut.  The 
interpreter  tries  to  match  a(2)  with  b(0)  and  b(l)  as  it  did  in  the  previous  e.xample. 
before  finding  a  match  with  b(2).  Here  is  where  the  difference  between  the  two  examples 
lies.  When  the  second  match  is  reported  to  the  screen,  the  interpreter  will  not  continue  to 
search  for  additional  solutions.  Clearly  the  database  contains  one  more  match,  namelv  X 
=  3,  but  the  cut  effectively  “pruned"  any  other  possible  match  after  a(2)  from  the  search- 
tree.  If  the  first  fact  of  the  program  (a(l))  were  swapped  with  the  second  one  (a(2) 

!),  the  search-tree  would  be  even  more  severelv  pruned  .  The  execution  of  the  query  would 
result  in  only  one  answer,  X  =  2. 

It  is  important  that  the  modification  of  the  control  strategy  should  only  affect  the 
behavior  of  the  computer  and  not  the  meaning  of  the  program  [36:429].  For  e.xample. 
a  programmer  may  want  to  go  to  a  local  convenience  store.  If  he  were  to  write  a  logiv 
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program  outlining  all  the  methods  of  transportation  available,  along  with  the  constraintb 
relating  them,  the  computer  could  be  used  to  suggest  the  best  method  of  travel  given  a 
set  of  existing  conditions.  One  such  condition  might  be  that  it  is  raining;  in  such  a  case, 
walking  would  not  be  appropriate.  The  control  of  the  program's  execution  could  be  altered 
to  exclude  exploring  any  modes  of  transportation  that  would  expose  the  programmer  to  the 
elements.  By  doing  so,  the  execution  of  the  program  is  made  more  efficient  by  immediately 
ruling  out  entire  classes  of  inappropriate  solutions:  no  time  is  wasted  exploring  unfruitful 
paths. 

Importance  of  Ordering  Clauses  and  Goals.  Limitations  imposed  by  the  in¬ 
terpreter  require  the  programmer  to  give  careful  consideration  to  the  order  in  which  the 
clauses  of  a  program  and  the  goals  of  a  body  are  listed.  Improper  ordering  of  clauses  can 
affect  the  efficiency  of  the  search  process  and,  in  some  cases,  cause  the  program  not  to 
execute  properly.  Consider  the  rule 

ancestor(X,Y) 
ancestor(X,Z) , 
parent(Z,Y) . 

which  can  be  interpreted  literally  as  “X  is  an  ancestor  of  Y  if  X  is  an  ancestor  of  Z  and  Z  is  a 
parent  of  Y”.  The  ordering  of  the  two  goals  of  the  body  makes  logical  sense  but  when  the 
Prolog  interpreter  attempts  to  invoke  the  procedure,  the  first  goal  recursively  calls  itself, 
creating  an  infinite  loop.  If  the  two  goals  in  the  body  are  swapped,  the  logical  meaning  of 
the  rule  is  preserved  but  the  interpreter  will  attempt  to  satisfy  the  parent-goal  first  and  an 
infinite  loop  will  not  result.  Often,  careless  ordering  of  clauses  will  not  cause  a  program  to 
execute  improperly  but  will  alfect  the  efficiency  of  e.xecution.  Efficien.y  of  e.xecution  can 
be  affected  by 

1.  the  order  of  appearance  of  procedures  in  a  program; 

2.  the  order  of  appearance  of  clauses  in  a  procedure;  and 

.3.  the  order  of  appearance  of  goals  in  a  rule  body. 

2. 2. 2. 4  Recursion.  The  second  clause  in  the  member  example  given  earlier 
warrants  further  discussion  as  it  exploits  the  concept  of  recursion.  Recursion  is  one 
of  the  most  powerful  features  of  Prolog  because  recursion  can  be  exploited  to  perform 
repetitive  tasks  [6j.  In  ’  nember  example,  each  time  X  is  not  the  element  at  the  head  of 


2-13 


the  list,  rule  1  fails.. and  the  interpreter  descends  another  level  of  recursion  until  X  occurs 
at  the  head  of  the  list  or  Rest  is  e.xhausted.  Each  time  rule  2  is  invoked,  the  tail  of  our 
list  will  be  successively  divided  into  an  instantiation  for  Y  and  Rest  until  the  end  of  the 
list  is  encountered.  The  end  of  a  list  is  denoted  by  an  empty  list  (“(]”)  and  is  used  to  form 
a  boundary  condition.  Using  the  empty  list  to  form  a  boundary  condition  for  the  member 
example  can  be  interpreted  literally  as  telling  the  Prolog  interpreter  “if  you  look  through 
the  entire  list  of  candidate  elements  and  cannot  find  an  occurrence  of  X  then  stop  your 
search  because  X  is  not  a  member  of  the  list”.  For  this  particular  example,  the  boundarv 
condition  does  not  need  to  be  stated  explicitly  because  the  interpreter  will  progressivelv 
e.xamine  the  elements  of  the  list  starting  from  the  head  and  working  towards  the  tail.  If  the 
end  of  the  list  is  encountered  ([]),  there  could  not  have  been  an  occurrence  of  X  in  the  list; 
hence,  the  search  fails  and  the  interpreter  stops  looking.  Figure  2.2  shows  the  e.xecution  of 
the  simple  question,  “is  3  a  member  of  the  list  [1,2,3]?”,  formally  stated  in  Prolog  as  the 
query  ?-member(3,  [1,2,3]) . 

Most  logic  problems  require  the  boundary  conditions  to  be  explicitly  declared  in  order 
to  avoid  infinite  loops.  If  a  nonjnember  procedure  were  desired,  the  boundary  condition 
would  have  to  be  explicitly  defined  in  order  to  instruct  the  interpreter  when  to  stop  looking. 
The  boundary  condition,  written  in  Prolog,  would  look  like 

non_member(X, [] ) 

and  would  be  literally  interpreted  as  “it  is  true  that  X  is  not  a  member  of  an  empty  list”. 
The  remainder  of  the  prolog  code  for  nonjnember  is 

non_member(X, [YlL]) 

X  \==  Y, 

non_member(X ,L) . 

where  \==  stands  for  strict  inequality. 

2.2.3  Summary.  Some  of  the  virtues  of  Prolog  have  been  briefly  explained  in  this 
chapter.  .4  general  summary  of  the  characteristics  that  make  Prolog  useful  in  digital  circuit 
design  are  [27:16j: 
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?-  member(3,[l,2,3]). 


rule  1 
XI  =3 
Y1  =  I 
Restl  = 


Figure  2.2.  Recursion  levels  for  the  query  ?-member(3,  [1 ,2,3] ) . 


1.  It  carries  out  symbolic  inferencing.  New  facts  or  rules  can  be  inferred  from  existing 
ones. 

2.  It  uses  an  orderly  search  process  in  its  execution  to  find  all  possible  solutions  within 
a  problem  space. 

3.  It  can  be  treated  as  both  a  declarative  and  a  procedural  programming  language. 
The  execution  of  a  program  may  be  altered  by  changing  the  structure  of  the  logic 
description  of  a  problem  or  the  sequence  of  execution  or  control  may  be  altered. 

4.  Prolog  programs  can  modify  themselves.  A  program  can  construct  a  new  fact  or 
rule  as  it  runs  and  add  the  fact  or  rule  to  itself.  Facts  or  rules  can  also  be  retracted 
from  the  rule  base.  This  means  that  Prolog  programs  can  “learn”  as  they  proceed 
through  the  execution  of  a  program  [l9].  An  example  of  this  can  be  found  in  the  the 
TTL  digital  circuit  simulator  presented  in  Chapter  5.  The  simulator  derives  rules 
concerning  the  gate-level  structure  of  the  circuit  under  test  and  uses  these  new  rules 
to  simulate  the  circuit’s  operation. 
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III.  Modeling  Digital  Circuits  with  Prolog 


3.1  Introduction 

The  versatility  of  Prolog  makes  it  ideal  for  modeling  logic  circuits.  Functional  and 
physical  characteristics  of  primitive  gates  as  well  as  higher-level  modules  can  easily  be 
modeled.  Prolog  supports  the  modeling  of  circuits  in  a  hierarchical  fashion.  Model'  £ 
circuits  hierarchically  allows  lower-level  intra-modular  connections  to  be  “hidden"  from 
the  view  of  upper-level  circuit  descriptions.  This  allows  the  design  engineer  to  specify  the 
internal  connections  of  a  module  once  as  a  template  and  then  to  reuse  the  template  as 
needed  to  design  new  circuitry. 

3.2  Circuit  Composition 

A  circuit  is  composed  of  sets  of  modules  and  their  interconnections.  Modules  can  be 
defined  hierarchically,  where  modules  are  defined  in  terms  of  other  modules.  At  the  bottom 
of  the  hierarchy  reside  the  primitive  modules  whose  identity  depends  on  the  technology 
being  modeled.  Digital  designers  may  consider  gates  or  individual  packages  to  be  primitive 
while  a  VLSI  designer  would  consider  transistors  to  be  primitive  (14:61).  Circuits  that  lack 
any  hierarchical  structure  are  referred  to  as  “flattened”  circuits. 

5.3  Circuit  Representation 

There  are  three  brisic  methods,  described  in  the  following  paragraphs,  used  to  rep¬ 
resent  digital  circuits  (14)  in  Prolog.  The  functional  method  uses  terms  to  functionally 
describe  circuits,  the  extensional  method  uses  a  database  of  facts  to  assert  connection 
relationships,  and  the  definitional  method  uses  formulae  to  model  the  circuit  definitions. 

The  Functional  Method  [14:61].  This  method  can  be  used  to  represent  circuits 
in  which  a  single  output  signal  is  a  function  of  .several  input  signals  [10:391].  Functions  can 
have  an  arbitrary  number  of  inputs  but  represent  only  one  output.  Inputs  are  e.'cpressed 
as  a  module’s  arguments.  Modules,  that  can  be  either  higher-level  or  primitive,  are  named 
according  to  the  function  they  perform.  For  e.Kample,  the  term 
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would  be  used  to  express  a  two-input  OR-gate.  Figure  3.1  shows  an  example  of  a  higher- 
level  circuit  constructed  of  NAND-gates.  Using  the  functional  method,  the  output  signal, 
Z,  would  be  expressed  as 

nand(nand(X,nand(X,Y)) ,nand(nand(X,Y) ,Y)) . 

Note  that  the  connectional  relationship  between  modules  is  purely  functional  with  the 
syntactic  form  determining  the  connections. 

This  type  of  representation  has  two  main  disadvantages  [10:392).  First,  only  circuits 
that  have  no  feed-back  loops  can  be  described:  therefore  most  sequential  circuits  can  not  be 
accurately  modeled  with  this  method.  Secondly,  each  output  must  be  represented  with  a 
separate  expression.  This  makes  hierarchical  representations  described  with  the  functional 
method  difficult  to  understand. 

The  Extensional  Method  [14:62]  The  extensional  method  represents  each  mod¬ 
ule  and  its  connections  as  separate  facts.  In  the  example  below,  the  module  predicate  has 
the  following  general  form: 

module (Name, List_of_input .ports, List_of_ou-cput_ports) . 

The  binary  predicate  connect  describes  the  connections  between  the  ports  in  the  following 
manner: 


d 
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connect(Specific_port, Connection) . 

Connections  between  modules  are  specified  with  the  connect  predicate.  This  pred¬ 
icate  has  two  arguments,  the  first  indicating  the  module  type  and  the  second  indicating 
the  connected  port  [14:62].  Figure  3.2  would  be  described  as 

module (xor , [a , b]  ,  [c] ) . 
module (not, [a] ,  [b] ) . 
module (jkff, Cj ,c,k3 , Cq,nq]) . 

connect(xor(a) ,out) . 
connect (xor(b) ,x) . 
connect(xor(c) ,cjkff (j)) . 
connect (xor (c) ,not(a)) . 
connect (not (b) .cjkff (k)) . 
connect(clock,cjkff (c)) . 
connect (jkff (q) ,out) . 

The  module  and  connect  predicates  should  be  considered  as  generic  templates.  When 
the  arguments  of  the  predicates  are  instantiated,  the  combination  of  both  predicates  repre¬ 
sents  an  instance  of  a  circuit  component  (provided  by  the  module  predicate)  and  a  complete 
description  of  the  component’s  circuit  connetiions  (provided  by  the  connect  predicate) 
[14:63].  Only  one  module  fact  is  needed  for  each  circuit  component  to  be  modeled.  How¬ 
ever,  a  large  number  of  connect  predicates  could  be  needed  to  describe  the  component's 
circuit'connectivity;  the  exact  number  requited  is  dependent  on  the  number  of  other  circuit 


devices  to  which  the  component  is  connected.  Since  the  simplest  component  must  have 
at  least  one  input  node  and  one  output  node,  the  minimum  number  of  coiinect  facts  per 
component  is  two.  Note  that  the  XOR-gate  module  described  in  the  code  given  above 
needs  one  module  fact  and  four  connect  facts  to  completely  describe  its  relationship  in 
the  circuit. 

This  method  can  be  used  to  model  sequential  as  well  as  combinational  circuits.  How¬ 
ever,  because  the  modules  are  represented  with  no  syntactic  relationship  between  them¬ 
selves  and  their  connections  (one  module  fact  for  each  module  type  and  two  or  more 
connect  facts  for  the  connections),  some  operations  such  as  circuit  transformations  are 
hard  to  implement  without  resorting  to  awkward  modifications  of  the  database.  For  exam¬ 
ple,  suppose  a  logic  program  were  written  to  identify  modules  that  could  be  removed  from 
a  circuit  without  affecting  the  circuit’s  behavior.  Once  a  redundant  module  were  located, 
it  would  need  to  be  identified  so  the  remaining  modules  in  the  circuit  could  be  reconnected 
without  the  redundant  module.  If  the  modules  are  extensionally  defined,  there  is  no  way 
to  identify  a  single  module  e.xcept  through  the  connect  pr,  Jicates.  The  extra  operations 
necessary  to  manipulate  the  structural  description  in  order  to  compensate  for  the  removed 
module  would  be  awkward.  The  simulation  of  faults  would  also  be  awkward  if  the  circuit 
under  test  were  described  extensionally.  Often  the  modeling  of  a  single-gate  failure  is  de¬ 
sired.  If  there  is  no  syntactic  way  to  describe  e.xactly  which  individual  gate’s  failure  is  to  be 
modeled,  the  simulation  can  not  be  carried  t  t.  However,  despite  the  inadequacies  of  the 
extensional  method,  it  has  proven  useful  in  applications  related  to  logic  circuit  modeling 
(9.  10,  14). 

The  expression  of  modularity  is  very  difficult  with  either  the  functional  or  the  exten¬ 
sional  methods.  In  contrast,  a  method  of  modeling  that  employs  single  terms  to  describe 
both  a  module  and  its  connections  can  be  used  to  express  modularity  much  more  easilv. 
The  third  method,  the  definitional  method,  circumvents  the  disadvantages  of  the  precious 
two  methods  by  combining  the  advantages  of  both. 

The  Definitional  Method.  The  definitional  method  [39:6-3],  used  throughout  this 
thesis,  represents  modules  having  n  ports  as  n-ary  predicates.  A  Horn-clause  is  lu-ed  ty 
describe  a  module:  the  head  of  the  clause  names  the  module  to  be  defined  and  the  bod> 
names  a  combination  of  lower-level  and  primitive  modules.  Individual  modules  within  « 
higher-level  module  are  listed  as  subgoals  of  that  module;  the  structure  and  internal  ar 
guments  of  each  subgoal  are  “hidden’’  from  the  higher-level  description.  This  “hiding" 
of  lower-level  module  descriptions  allows  the  definitional  method  to  be  used  to  describe 
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circuit  organization  in  a  hierarchical  fashion  without  involving  extra  predicates  or  argu¬ 
ments.  Ports  that  share  a  common  connection  are  represented  with  like-name  (coreferred) 
variables.  A  half-adder,  for  example,  can  be  represented  hierarchically  as  shown  in  Fig¬ 
ure  3.3.  Note  that  the  XOR  function  can  be  represented  by  the  NAND-gate  configuration 
of  Figure  3.1. 

The  definitional  method  of  representing  a  half-adder  easily  accommodates  the  hierarchical 
p-i'  ;re  of  the  circuit  and  allows  connections  to  be  described  in  a  very  understandable 
ir.  ’iiv  as  illustrated  by  Figure  3.3  and  shown  by  the  following  code  [13:497]: 

half_addGr(X,Y,S,C)  :- 
xor_gate(X,Y,S) , 
and„gate(X,Y,C) . 

The  predicate  xor^ate  can  be  ’"'cdeled  as  a  higher-level  module  in  terms  of  primitive 
NAND-gates  (see  Figure  3.1)  with  the  following  code: 

xor_gate(X,Y,Z) 
nand_gate(X,Y,Tl) , 
nand_gate(Tl ,X,T2) , 
nand_gate(Y,Tl,T3) , 
nand_gate(T2,T3,Z) . 

The  status  of  a  module  (higher-level  or  primitive)  can  be  stated  with  a  simple  primitive 
predicate  and  one  argument  as  follows: 

primitive(nand) . 

prirait:ive(and) . 


3-5 


All  modules  not  specified  as  primitive  are  assumed  to  be  higher-level. 

The  definitional  method  does  not  explicitly  declare  the  input  or  output  status  of 
a  module  as  did  the  two  methods  discussed  previously.  If  it  is  necessary  to  know  the 
direction  of  the  ports,  another  simple  predicate  can  be  used.  The  predicate  direction  can 
be  written  explicitly  for  N.-VND-modules  as 

outputs 

directioninand{A,  B,C},[A,  B],  (C)  ). 

inputs 

A  variation  of  the  definitional  method  incorporates  the  direction  of  the  ports  directly  into 
the  module  predicate  [•31:28.5].  For  example,  the  predicate  halfadd  can  also  be  written  as 

half_adder(in(X,Y) ,out(S,C)) 
xor_gate(in(X,Y) ,out(S)) , 
and_gate(in(X,Y) ,out(C)) . 

The  definitional  method  of  modeling  has  several  advantages.  Most  important  is 
the  fact  that  the  module  name  is  e.xplicitly  part  of  the  specification,  permitting  easy 
decomposition.  Consider  the  half-adder  of  Figure  3.3.  Internal  connections  that  are  named 
with  variables  do  not  appear  in  the  head  of  the  clause  and  are  effectively  hidden  as  are 
connections  of  lower  levels  in  the  hierarchy.  This  allows  simple,  primitive  modules  to 
be  easily  arranged  into  more  complex  circuits  without  a  corresponding  increase  in  the 
difficulty  in  comprehending  the  overall  circuit’s  function.  The  Prolog  code  used  to  represent 
the  higher-level  modules  is  also  easy  to  compose  and  understand.  This  method  also  has 
several  other  advantages  (14:64]: 


1.  Prolog  can  execute  circuit  simulations  directly  from  module  descriptions. 

2.  An  uninstantiated  variable  is  a  natural  representation  of  a  high-impedance  state. 

3.  Circuits  can  be  manipulated  automatically  by  recursively  decomposing  their  hierar¬ 
chical  structure. 


The  definitional  method  has  been  used  with  considerable  success  to  model  and  simu¬ 
late  digital  circuits  [23,  24,  36).  Complex  combinational  and  sequential  circuits  have  been 
explored  and  favorable  results  reported. 
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[V.  Logic  Programming  for  Circuit-Extraction 

4. 1  Introduction 

A  logic  circuit  designer  would  normally  work  with  high-level  constructs  such  as  reg¬ 
isters  and  buses,  seldom  descending  to  the  level  of  gates  [~:5].  However,  gate-level  descrip¬ 
tions  do  play  an  important  role  in  design,  especially  during  the  layout  process.  Designing 
an  actual  integrated  circuit  requires  a  netlist.  .A.  netlist  specifies  the  type  of  primitive 
components  (transistors  or  gates)  necessary  to  realize  the  desired  function,  along  with  their 
interconnections.  .A  typical  netlist  is  made  up  of  transistors.  However,  for  this  discussion. 
.A'AND-gates  will  be  considered  primitive  for  simplicity. 

While  a  netlist  is  suitable  for  describing  circuit  structure  for  the  manufacturing  pro¬ 
cess,  it  is  a  formless  mass  of  primitive  components  which  can  be  almost  unintelligible  to 
the  designer.  Circuit-e.xtraction  can  be  used  to  redefine  a  circuit's  netlist  by  rearranging 
a  circuit’s  modular  structure  into  something  more  easily  understood.  E.Ktraction  removes 
groups  of  lower-level  components  from  a  netlist  and  replaces  them  with  a  corresponding 
higher-level  component.  E.xtraction  can  help  the  designer  to  understand  his  own  design  or 
reverse-engineer  (decipher  something  already  designed)  someone  else's  design  by  recogniz¬ 
ing  groupings  of  lower-level  components  that  constitute  a  higher-level  component. 

Prolog  is  an  ideal  language  to  use  for  the  e.xtraction  process  because  e.xtraction  is 
based  on  the  recognition  of  patterns  and  Prolog  is  a  pattern-niatching  language.  Only 
two  items  are  necessary  for  the  interpreter  to  carry  out  the  e.xtraction  process.  First,  the 
interpreter  needs  a  netlist  of  the  primitive  components  that  describe  the  circuit.  Second, 
it  needs  a  description  of  the  pattern  or  function  to  be  searched  for. 

In  the  following  e.xample,  the  interpreter  will  begin  with  a  netlist  composed  entireh 
of  N.A.N'D-gates.  First,  any  groupings  of  N.AND-gates  that  perform  XOR-gate  functions 
will  be  found.  The  appropriate  NAND-gates  and  their  connections  will  be  replaced  with 
the  higher-level  XOR-gate  construct  with  the  correct  connections.  The  interpreter  will 
then  look  for  groupings  of  N.AND-gates  and  XOR-gates  that  can  be  replaced  with  full- 
adders.  again  removing  the  appropriate  N.-V.ND  and  XOR-gates  with  their  connections  and 
replacing  them  with  full-adders  and  the  proper  connections. 

4.2  The  Circuit- Extraction  Process 

Defining  XOR-gates  in  Terms  of  NAND-gates.  Consider  the  simple  netlist 
(given  below)  consisting  of  four  two-input  N.AND-gates  described  using  the  definitional 
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Figure'Ll.  E.xtracting  an  XOR-gate. 


method.  Note  that  the  arguments  of  each  fact  have  been  instantiated  with  a  constant 
representing  a  nodal  position  or  connection  in  the  circuit. 

nand_gate(.x,y  ,tl) . 
nand_gate(x,tl,t2) . 
nand.gateCy ,tl ,t3) . 
nand_gate(t2,t3,z) . 

Once  loaded  into  Prolog’s  database,  the  netlist  can  be  scanned  and  the  four  NAND-gates 
recognized  as  performing  the  same  function  logically  as  a  two-input  XOR-gate  described 
by 

xor_gate(x,y ,z) . 

Figure  4.1  shows  the  circuit,  before  and  after  e.xtraction. 

When  the  netlist  is  loaded  into  Prolog's  database,  it  becomes  part  of  the  working 
program,  as  data  and  procedures  are  not  stored  separately.  Prolog  has  two  built-in  proce¬ 
dures  that  can  be  used  to  alter  the  dat.abase  bv  retracting  old  unwanted  facts  or  rules  and 
asserting  new  ones. 

The  built-in  predicate  retract(X)  erases  a  fact  or  rule  from  the  current  databa.se 
(16:106).  The  predicate  retract  takes  a  single  argument  X  that  is  to  match  the  clause 
to  be  retracted.  The  interpreter  proceeds,  lop  'o  bottom,  searching  through  the  databa-'-e 
until  a  match  is  made.  Once  the  match  is  made,  the  matching  clause  is  removed  from 
the  database.  Only  one  matching  clause  i.>  removed  each  time  retract  is  invoked.  If  it 
is  necessary  to  remove  si.x  clauses  (all  with  the  .same  name),  retract  would  have  to  be 
invoked  si.x  times. 

The  built  in  predicate  assert  (X)  adds  a  new  clause  to  the  database  [16:105).  assert 
comes  with  options  that  allow  the  clause  to  be  put  at  the  beginning  of  the  database 


Figure  4.2.  NAND  and  XOR-gatc  to  full-adder  conversion. 


(asserta(X))  or  at  the  end  of  the  database  {assertz(X)).  The  argument  X  must  be  an 
instantiated  clause  for  assert  to  succeed. 

Defining  a  Full-Adder  in  Terms  of  XOR  and  NAND-gates.  A  full-adder  is 
a  device  that  has  three  input-terminals,  each  carrying  a  single  binary  bit.  Functionally,  a 
full-adder  counts  the  number  of  its  inputs  that  have  a  value  of  1.  The  sum  of  the  inputs  is 
represented  with  two  output-terminals  as  a  two-digit  binary  number;  the  carry-bit  C  and 
the  sum-bit  S.  If  two  of  the  three  inputs  have  a  value  of  1  then  the  output  would  be  the 
number  CS  =  10,  which  is  the  binary  representation  of  the  decimal  value  2. 

A  full-adder  can  be  defined  in  terms  of  .N'.AND  and  XOR-gatcs  (see  figure  4.2).  Con¬ 
sider  the  following  netlist,  in  which  each  argument  has  again  been  instantiated  to  a  constant 
that  represents  a  circuit-node  or  connection  point. 

xor_gate(x,y,ti). 
nand_gai:e(x,y,t:2) . 
xor.gaeeCzjtl.s) . 
nand_gate(z,ti,t3) . 
naad_gat:e(v2,c3,c) . 

Once  loaded  into  prolog’s  database,  this  netlist  can  be  subjected  to  the  extraction 
process  and  the  five  gates  recognized  as  constituting  a  full  adder  described  by 

fail_adder(x,y,z,s,c) . 

Figure  4.2  shows  the  circui*.  before  and  after  extraction.  .After  the  Prolog  inlerpreicr 
recognizes  the  pattern  for  a  full-adder  in  the  netlist.  the  five  gates  arc  retracted  from  tii»* 
netlist  and  the  replacement  device  assertcil  to  fill  the  void. 

.j.3  The  Circuit- Exlraclion  Algorithm 

The  process  to  extract  full-adders  can  be  formally  stated  as 
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1.  Load  the  netllst  to  be  scanned  into  the  database. 

2.  Scan  the  netlist  for  all  possible  XOR-gate  instances  of  NAXD-gate  configurations. 
When  one  is  identified,  retract  the  NAND-gate  constituents  and  assert  the  replace¬ 
ment  XOR-gate. 

3.  Scan  the  revised  netlist  for  all  possible  full-adders.  Retract  the  appropriate  configu¬ 
rations  of  XOR  and  N.AND-gates  and  replace  them  with  full-adders. 

NAND-gate  configurations  that  can  be  replaced  by  XOR-gates  can  be  found  for 
particular  instances  with  the  following  code. 

xor_gate(X,Y,Z) 
nand_gate(X,Y,Tl) , 
naiid_gate(X  ,T1  ,T2) , 
nand_gdte(Y,Tl ,T3) , 
nand_gat3(T2,T3,Z) . 

When  comy-  d  against  a  netlist,  Prolog  will  instantiated  the  upper-case  letters,  which 
represent  variables,  with  the  netlist’s  lower-case  letters  which  represent  actual  nodal  con¬ 
nections,  The  xor.gate  clause  above  can  be  reused  as  often  as  is  necessary  to  completely 
scan  the  netlist  and  can  be  considered  a  generic  template  that  describes  the  general  con¬ 
nectivity  of  an  XOR-gate  to  the  interpreter.  If  the  interpreter  can  find  nodal  connections 
within  the  circuit  definition  that  fit  the  pattern  of  the  XOR-gate  template,  the  substitution 
will  take  place.  If  the  interpreter  matches  the  variables  in  three  of  the  four  NAND-gate 
goals  but  fails  to  find  a  match  for  the  fourth,  it  will  “undo”  the  first  three  goal’s  instan¬ 
tiations  and  proceed  with  another  combination  until  all  possible  permutations  are  tried. 
This  is  done  automatically  because  of  Prolog's  backtracking  ability.  In  an  actual  extrac¬ 
tion  program  the  goals  of  the  xor.gate  clause  must  be  modified  slightly  to  account  for  a 
transposing  of  the  input  values.  Each  goal  of  the  clause  should  succeed  without  regard 
to  the  order  of  the  input  value  arguments.  For  example,  the  goal  nand^ate(X,Y,Tl) 
should  be  accompanied  by  the  goal  nand.gate(Y,X,Tl);  thus  informing  the  interpreter 
that  either  arrangement  of  input  arguments  is  acceptable.  The  remaining  three  goals  of 
the  xor.gate  clause  require  similar  companion-goals  in  order  to  completely  describe  all 
the  possible  permutations  of  input  arguments  that  could  occur. 

In  a  similar  manner,  the  complete  code  for  defining  a  full-adder  is 
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full_adder(X,Y,Z,S,C) 

(nand_gate(X,Y,T2) 

nand_gate(Y,X,T2)) , 

(xor_gate(X,Y,Tl) 

> 

xor_gate(Y,X,Tl)) , 

(nand_gate(Z,Tl ,T3) 

> 

nand_gate(Tl,Z,T3)) , 

(xor_gate(Z,Tl ,S) 

xor_gate(Tl ,Z,S)) , 

(nand_gate(T2 ,T3 ,C) 

»  * 
nand_gate(T3,T2,C) ) . 

where  the  symbol  ;  denotes  a  disjunction. 

An  Abbreviated  Extraction  Session 

In  addition  to  the  code  discussed  previously  in  this  chapter,  a  netlist  of  components 
and  a  procedure  to  drive  the  extraction  process  are  needed  to  successfully  start  a  sample 
extraction  session.  The  code  necessary  to  drive  the  process  is 

extract_full_adders 
f ind_xor_gates, 
f ind_full_adders . 

The  procedures  f ind_xor.gates  and  f ind_full-adders  describe  the  pattern  of  NAND- 
gates  that  constitute  an  XOR-gate  or  a  full-adder  respectively.  A.  complete  listing  of  the 
code  is  given  in  Appendix  A. 

.‘Vny  netlist  can  now  be  subjected  to  the  extraction  process.  The  following  netlist  is 
provided  for  this  example: 


nand_gate(x,y ,tl) . 
nand_gate(y,tl ,t3) . 
nand_gate(x,tl ,t2) . 
nand_gate(t2,t3,t4) . 
nand_gate(t4,2,tl) . 
nand_gate(t4,tl,t2) . 
nand_gate(z,tl,t3) . 
nand_gate(t2,t3,s) . 
nand_gate(x,y ,t6) . 
nand_gate(z,t4,t5) . 
nand_gate(t6,t5,c) . 

which  describes  exactly  one  full-adder. 

Running  the  extraction  produced  the  following  short  script  session.  A  more  in  depth 
session  is  given  in  Appendix  A.  Comments  and  notes  that  are  not  a  part  of  the  actual 
script  session  are  set  off  with  the  standard  Prologl  comment  delimiter  /* . */. 

Script  VI. 0  session  started  Hon  Sep  02  12:44:22  1991 

Microsoft(R)  HS-DOS(R)  Version  4.01 

(C)Copyright  Microsoft  Corp  1981-1988 

J:\THESIS\CODE>prolog 

+ - + 

I  MS-DOS  Prolog-1  Version  2.2  I 

I  Copyright  1983  Serial  number:  0001213  I 

I  Expert  Systems  Ltd.  I 

I  Oxford  U.K.  I 

+ - + 

/*  The  following  command  loads  the  file  extract. pro.  The  file  contains  all  the  Prolog 
code  necessary  for  this  session.  */ 

?-  [extract] . 
extract  consulted. 

/*  invoking  the  algorithm.  */ 

?-  extract_full_adders . 
yes 

/*  The  built-in  predicate  “listing(X)’'  will  find  all  expressions  for  X  and  print  them  on  the 
screen.  */ 
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?-  listing(nand_gate) . 
yes 

/*  All  NAND-gates  are  gone.  */ 

?-  listing(xor_gate) . 
yes 

/*  All  XOR-gates  are  gone.  */ 

?-  listing(full_adder) . 
full_adder(x,y,z,s,c)  . 
yes 

/*  One  full-adder,  with  the  proper  nodal  connections,  was  found.  */ 

?-  halt. 

/*  Finished  .  */ 

J:\THESIS\CODE>exit 

Script  completed  Mon  Sep  02  12:46:22  1991 

There  are  several  ways  that  the  procedure  could  be  made  more  efficient,  but  this 
would  adversely  affect  the  readability  of  the  code.  Efficiency  has  been  sacrificed  for  ease  of 
understanding.  For  e.xample,  one  helper  procedure  could  be  called  to  find  the  XOR-gate 
configurations  and  another  helper  procedure  called  to  retract  the  NAND-gates  and  assert 
the  XOR-gate.  However,  since  variables  are  only  known  within  the  scope  of  the  applicable 
procedure,  additional  parameters  would  have  to  be  set  up  and  passed. 
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y.  The  Simulation  of  Digital  Circuits  with  Logic  Programming 


5.1  Introduction 

A  digital  logic  circuit  can  be  viewed  as  a  network  of  modules,  both  higher-level 
and  primitive,  whose  interconnections  impose  constraints  on  the  circuit.  Satisfying  those 
constraints  with  some  connections  bound  to  constant  values  can  serve  to  simulate  the  op¬ 
eration  of  the  circuit  [31:233].  Conventional  modeling  programs  like  Spice  are  restricted 
to  quantitative  modeling  in  the  “forward”  direction  only  [31:284].  Circuit  modeling  with 
Prolog  does  not  suffer  from  the  same  limitations,  because  of  the  bidirectional  nature  of 
logic  programming  [23].  By  specifying  a  subset  of  the  inputs  to  a  circuit  under  test,  Prolog 
can  provide  all  possible  corresponding  output  values.  If  a  subset  of  the  output  values  is 
specified,  Prolog  can  provide  all  input  values  that  are  possible  under  those  circumstances. 
If  a  combination  of  input  and  output  values  is  specified,  Prolog  will  find  all  possible  com¬ 
binations  of  unspecified  input  and/or  output  values. 

Unlike  the  extraction  process  of  the  previous  chapter,  the  simulation  of  digital  cir¬ 
cuitry  does  not  involve  the  manipulation  of  nodal  connections.  Instead,  the  variables  in 
the  circuit  definitions  are  instantiated  with  Boolean  values,  either  0  or  1.  The  convention 
for  naming  functors  to  reflect  this  difference  is  discussed  in  Chapter  1. 

5.2  The  Simulation  of  Combinational  Circuits 

5.2.1  Primitive  Modules.  The  simulation  of  the  operation  of  combinational  circuits 
composed  of  primitive  modules  is  easily  accomplished  with  Prolog.  In  a  combinational  cir¬ 
cuit,  the  value  of  the  output  depends  only  on  the  present  value  of  the  input.  As  an  example, 
consider  a  circuit  that  contains  one  two-input  N.AND-gate.  .At  any  time,  each  of  the  input 
signals  may  be  at  one  of  two  voltage  levels;  these  are  represented  by  the  Boolean  values  0 
and  1.  The  output  of  the  NAND-gate  is  at  level  0  if  and  only  if  all  its  inputs  are  at  level 
1;  otherwise  the  output  is  at  level  1.  This  behavior  is  defined  by  the  truth-table  shown  in 
Table  5.1  where  X  and  Y  represent  input  signals  and  Z  represents  the  output  signal.  The 
operation  of  a  two-input  NAND-gate  can  be  de.scribed  in  Prolog  with  four  facts,  one  for 
each  row  of  the  Truth-table  (Table  5.1). 
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fact  1  nand(0,0,l). 

fact  2  nand(0,l,l) . 
fact  3  nand(l,0,l) . 
fact  4  nandd ,  1,0)  . 

Once  the  four  facts  describing  the  operation  of  a  NAND-gate  are  supplied  to  the 
Prolog  interpreter,  the  gate's  operation  can  be  simulated  forward  with  the  following  query: 

?-  nand(0,0,0ut) . 

Out  =  1 

more  (y/n)?  y 

no 

The  query,  directly  above,  asks  “if  the  two  input  signals  of  a  two-input  NAND-gate  are 
set  to  the  Boolean  value  0,  what  possible  values  can  the  output  variable  Out  hold 
The  NAND-gate  truth-table  shows  that  only  one  value  exists  for  the  given  combination  of 
.inputs.  Out  =  1.  Simulation  in  the  backward  direction  is  also  possible.  The  query 

?-  nand(X,l,0ut) . 

will  yeild  the  following  response  from  the  interpreter. 

X  =  0 

Out  =  1 

more  (y/n)?  y 


X  =.  1 
Out  =  0 
more  (y/n)?  y 
no 


Table  5.1.  .NAND-gate  truth-table. 


X 

Y 

Out 

0 

0 

1 

0 

1 

1 

1 

0 

1 

1 

1 

0 
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Table  5.2.  XOR-gate  truth-table. 


X 

Y 

Out 

0 

0 

0 

0 

1 

1 

1 

0 

1 

1 

1 

0 

5.2.2  Higher-Level  Modules.  In  order  to  simulate  the  operation  of  a  higher-level 
module,  it  must  be  defined  in  terms  of  lower-level  modules.  At  the  bottom  of  the  module 
hierarchy  are  the  primitive  submodules.  Consider  an  XOR-gate.  The  output  of  an  XOR- 
gate  produces  the  modulo-2  sum  of  all  its  inputs  [T;2].  Since  the  range  of  the  input  values 
is  limited  to  either  the  Boolean  value  0  or  1,  the  operation  of  an  XOR-gate  may  be  thought 
of  as  counting  the  number,  N,  of  the  XOR-gate’s  1-inputs.  If  N  is  odd,  the  output  signal 
level  is  1;  if  N  is  even,  the  output  is  0.  Table  5.2  defines  this  behavior  for  a  two-input 
XOR-gate. 

In  order  to  simulate  the  operation  of  an  XOR-gate,  two  approaches  are  possible. 
First,  the  gate  could  be  declared  as  a  primitive  gate  and  the  values  in  Table  5.2  listed  as 
facts  in  the  database,  similar  to  the  procedure  described  for  the  NAND-gate  or  second, 
the  XOR-gate  function  could  be  modeled  hierarchically  in  terms  of  other  modules.  Taking 
the  latter  approach,  one  of  many  possible  ways  to  construct  a  digital  circuit  that  behaves 
as  an  XOR-gate  is  shown  in  Figure  .3.1.  This  hierarchical  representation  can  be  simulated 
if  the  constituent  NAND-gates  are  declared  primitive  and  the  NAND-gate  truth-table  (see 
Tabic  5.1)  entered  into  the  database.  .\11  that  would  be  needed  to  initiate  a  query  would 
be  the  rule  that  defines  the  XOR-gate  hierarchically  in  terms  of  NAND-gates.  The  rule, 
coded  in  Prolog,  would  be 

xor(X,Y,Z) 
nand(X,Y,Tl), 
nand(X,Tl,T2), 
nand(Y,Tl,T3), 
nand(T2,T3,Z) . 

When  the  simulator  is  presented  with  the  query 
?-  xor(l,l,Z) . 
the  following  actions  take  place: 
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1.  The  first  goal  of  the  XOR  rule,  nand(X,y,Tl)  has  both  X  and  Y  instantiated  to  the 
value  of ‘T’’  because  of  the  format  of  the  query.  Nand-fact  4  (see  page  5-2)  can  satisfy 
the  first  goal  if  T1  is  instantiated  to  the  value  of  “0”.  With  this  done,  the  second 
goal  now  reads  nand(l,0,T2). 

2.  Nand-fact  3  can  satisfy  the  second  goal  if  T2  is  instantiated  to  the  value  of  "1'’.  With 
this  done,  the  second  goal  is  now  satisfied  and  the  interpreter  attempts  to  satisfv  the 
third  goal,  nand(l ,0,T3). 

3.  The  third  goal  can  be  satisfied  through  the  application  of  nand-fact  3  also.  This 
instantiated  T3  to  the  value  of  “1”.  The  interpreter  now  moves  on  to  the  fourth  goal, 
nand(l,l,Z). 

4.  Nand-fact  4  can  be  used  to  satisfy  the  fourth  goal  of  the  XOR  rule  resulting  in  Z  being 
instantiated  to  0.  The  interpreter  has  now  found  one  possible  solution  and  correctlv 
reports  Z  =  “O’’  as  the  result.  In  this  e.Kample,  no  more  solutions  are  possible  as  no 
more  nand-facts  can  be  used  to  satisfy  the  XOR  rule’s  goals. 

Applying  this  approach,  Prolog  allows  the  operation  of  very  complex  hierarchically- 
designed  circuits  to  be  simulated  with  ease.  For  circuits  having  large  numbers  of  input  lines, 
the  simulation  of  all  modes  of  operation  is  not  practical;  if  done  with  discretion,  howe\er. 
simulation  does  provide  the  designer  with  a  reasonable  degree  of  confidence  in  his  design 
[7:4j.  The  following  bidirectional  simulation  of  a  four-bit  adder  serves  to  illustrate  the 
usefulness  of  the  simulation  of  complex  digital  circuitry  with  Prolog. 

5.2.2. 1  Defining  a  Full- Adder  in  Terms  of  XOR-Gates  and  NAND-Cates.  .\ 
full-adder  is  a  device  that  has  three  input-terminals  and  two  output-terminals.  The  range 
of  the  input  and  output  values  is  limited  to  the  Boolean  values  of  0  or  1  just  as  was 
done  in  the  previous  e.\amples.  The  outputs  are  labeled  (by  convention)  C  (carry)  and  S 
(sum).  The  ope.ation  of  a  full-adder  is  similar  to  that  of  an  XOR-gate  in  that  it  counts  the 
number,  N,  of  its  inputs  that  have  the  value  1.  The  value  of  N  is  displayed  at  the  output 
of  the  full-adder  as  a  two-bit  binary  number.  For  example,  if  all  three  inputs  have  the 
value  1,  then  the  output  would  be  CS  =  11,  or  binary  3.  full-adder  was  defined  in  term.s 
of  XOR-  and  N.-\ND-gates  in  the  previous  chapter.  The  schematic  representation  of  a 
full-adder  is  shown  in  Figure  4.2.  Each  XOR  gate  in  the  full-adder  can  be  modeled  by  fotir 
N.4ND-gates;  hence  a  flattened  representation  of  a  full-adder  could  contain  as  many  as  11 
two-input  NAND-gates.  The  conventional  symbol  for  a  full-adder  is  shown  in  Figure  3.1. 
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X3  Y3 


X2  Y2 


XI  Y1 


XO  YO 


S3  S2  SI  SO 

Figure  5.2.  Four-bit  binary  adder  constructed  from  full-adders. 


5.2.2.2  'defining  an  n-Bit  Binary-Adder  in  Terms  of  Full-Adders.  An  n-bit 
binary  adder  works  in  a  fashion  similar  to  that  of  the  full-adder.  The  n-bit  binary  adder 
produces  a  binary  sum  represented  by  n-|-l  output  bits  given  two  n-bit  binary  numbers  as 
inputs.  Figure  5.2  shows  a  four-bit  binary-adder. 

Consider  the  following  netlist 

full_adder(X0,Y0,0,C0,S0) . 
full_adder(Xl,yi,CO,Cl,Sl). 
full_adder(X2,Y2,Cl,C2,S2) . 
full_adder(X3,Y3,C2,C3,S3) . 

that  models  the  circuit  shown  in  Figure  5.2.  Note  that  the  value  of  the  signal  on  the  input 
carry  line  has  been  set  to  0  for  convenience.  The  netlist’s  operation  can  be  simulated  by 
defining  its  head  functor  and  arguments  as 

four_bit_adder(bin(X3,X2,Xl,X0) ,bin(Y3,Y2,Yl ,Y0) ,bin(C3,S3,S2,Sl ,S0)) . 

Note  that  there  is  no  actual  procedure  named  bin.  The  functor  bin  is  used  for  pattern¬ 
matching  and  allows  the  arguments  of  the  adder  to  be  grouped  into  a  more  recogni2able 
form.  Also  note  that  the  functor,  bin,  does  not  have  the  same  number  of  arguments  in  all 
cases.  Prolog  will  recognize  this  and  treat  the  functors  with  different  numbers  of  arguments 
as  different  functors.  The  complete  Prolog  code  that  describes  the  operation  of  a  four-bit 
adder  is 
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four_bit_adder(bin(X3 ,X2 ,X1 ,X0) ,bin(Y3 , Y2 , Y1 , YO) ,bin(C3 ,S3 ,S2 ,S1 ,SO) ) 
full_adder(X0,Y0,0,C0,S0) , 
full_adder(Xl,Yl,CO,Cl,Sl), 
full_adder(X2,Y2,Cl,C2,S2). 
f ull.adder (X3 , Y3 , C2 , C3 , S3) . 

It  is  interesting  to  note  that  a  flattened  four-bit  binary  adder  would  require  44  NAND- 
gates.  Construction  and  simulation  of  a  44  gate  circuit  is  considerably  more  difficult  if 
advantage  of  the  hierarchical  structure  is  not  taken. 

5.2.3  An  Example  of  a  Four-Bit  Binary  Adder  Simulation.  The  simulation  of  the 
operation  of  a  four-bit  binary  adder,  modeled  hierarchically  with  NAND-gates,  can  be 
accomplished  with  the  code  discussed  above.  The  required  code  is  repeated  in  a  consoli¬ 
dated  form  in  file  addrcode.pro  located  in  .Appendi.K  B.  Comments,  that  are  added  to  the 
simulation  session  for  clarification,  are  set  of  with  the  standard  Prolog-1  comment  synta.x 
■/* . */. 

Script  VI. 0  session  started  Hon  Sep  09  09:24:35  1991 

Microsoft(R)  MS-DOS(R)  Version  4.01 

(C)Copyright  Microsoft  Corp  1981-1988 


J:\>prolog 

+ - + 

1  MS-DOS  Prolog- 1  Version  2.2  I 

I  Copyright  1983  Serial  number:  0001213  I 

1  Expert  Systems  Ltd.  I 

I  Oxford  U.K.  I 

+ - + 

/*  This  command  loads  the  file  which  contains  the  code  necessary  for  the  simulation  to 
take  place.  */ 

?-  [addrcode] . 
addrcode  consulted. 


/*Test  with  all  inputs  set  equal  to  zero.  */ 


?-  bin_adder(bin(0, 0,0,0) ,bin(0,0,0,0) ,bin(C3,S3,S2,Sl,S0)) . 


C3  =  0 
S3  =  0 
S2  =  0 
SI  =  0 
SO  =  0 

More  (y/n)?  y 
no 

/*Reverse  simulation  test.  Given  that  all  X  inputs  are  set  to  zero  and  the  output  is  given 
as  binary  1,  what  must  value  at  Y  have  been  ?  *  j 

?-  bin_adder(bin(0, 0,0,0) ,Y,bin(0,0,0,0,l)) . 

Y  =  bin(0, 0,0,1)  /^correct  value*/ 

More  (y/n)?  y 

no 

/*With  the  output  set  at  1,  find  all  possible  input  combinations.  */ 

?-  bin_adder(X,Y,bin(0,0,0,0,l)) . 

X  =  bin(0, 0,0,0)  /*one  of  two*/ 

Y  =  bin(0, 0,0,1) 

More  (y/n)?  y 

X  =  bin(0, 0,0,1)  /*two  of  two*/ 

Y  =  bin(0, 0,0,0) 

More  (y/n)?  y 

no 

?-  halt. 

J:\>exit 

Script  completed  Mon  Sep  09  09:31:51  1991 

More  detailed  simulation  results  for  a  four  bit  binary  adder  along  with  a  complete  listing 
of  the  associated  Prolog  code  are  included  in  .-Vppendi.x  B. 

5.3  The  .Simulation  of  Sequential  Circuits 

Sequential  circuits  are  more  difficult  to  simulate  than  combinational  circuits  because 
any  output  depends  on  both  the  present  and  past  input  values  (•ll;949].  .A.  sequential 
network  effectively  has  a  “memory"  because  it  must  remember  something  about  the  past 
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sequence  of  inputs.  .4  combinational  circuit  has  no  such  memory.  A  sequential  network 
is  composed  of  a  combinational  network  and  some  added  memory  elements.  The  memory 
function  in  sequential  networks  is  performed  by  memory  devices,  some  of  which  are  flip- 
flops,  counters,  and  shift-registers.  Since  flip-flops  are  the  most  basic  memory  device,  this 
discussion  will  focus  on  simulating  sequential  circuits,  all  of  whose  memory  elements  are 
flip-flops. 

One  of  the  most  widely  used  members  of  the  flip-flop  family  is  the  JK  flip-flop.  .4 
JK  flip-flop  can  be  represented  with  the  with  the  relation 

jkff(J,K,Ps,Ns). 

where  J  and  K  are  input  terminals,  Ps  is  the  present  state  and  Ns  the  ne.Kt  state.  To  create 
a  program  that  simulates  the  operation  of  a  JK  flip-flop,  the  complete  operation  of  the  flip- 
flop  must  be  specified  and  the  appropriate  code  added  to  the  database.  The  following  code, 
derived  from  Table  5.3,  specifies  the  operation  of  the  JK  flip-flop.  Since  all  JK  flip-flops 
are  clocked  on  either  the  leading  or  trailing  edge  of  the  clocking  pulse,  actual  JK  flip-flops 
must  be  supplied  with  an  adequate  clocking  pulse  in  order  to  operate  properly.  However, 
the  simulation  of  flip-flop  operation  is  possible  without  specifying  any  input  clock  pulse 
because  each  clock  cycle  is  represented  as  one  recursive  call  to  the  simulation  procedure. 
During  any  one  cycle,  all  next-state  values  Ns  are  found  from  the  combination  of  present- 
state  values,  J,  K,  and  Ps.  Realizing  that  a  clock  pulse  is  superfluous  allows  the  JK 
flip-flop  to  be  modeled  without  specifying  a  clocking  sequence.  The  code  that  describes 
the  complete  operation  of  a  JK  flip-flop  is 

jkff (0,0,0,0) . 
jkffCO, 0,1,1). 
jkff(0, 1,0,0). 
jkffCO, 1,1,0). 
jkffd, 0,0,1). 
jkff (1,0,1, l) . 
jkffd, 1,0,1). 
jkff (1,1, 1,0). 

Since  the  operation  of  a  flip-flop  requires  the  specification  of  an  input  sequence  of 
J,  K,  and  Ns  values,  recursion  is  used  to  simulate  sequential  operation.  Simple  recursive 
routines  are  necessary  in  order  to  “feed”  the  input  values  to  the  device  in  a  serial  fashion. 
.4  verbal  description  of  the  algorithm  necessary  to  simulate  JK  flip-flop  operation  would 


Table  5.3.  State  transition  table  for  a  .JK  flip-flop. 


J 

K 

Ps 

Ns 

0 

0 

0 

0 

0 

0 

1 

1 

0 

i 

0 

0 

0 

1 

1 

0 

1 

0 

0 

1 

1 

0 

1 

1 

1 

1 

0 

1 

1 

1 

1 

0 

be: 


1.  Using  the  Heads  of  the  J  and  K  input  lists,  and  the  present  state  Ps,  find  the  value 
of  the  ne.xt  state  Hs. 

2.  Continue  the  simulation  with  the  tails  of  the  J  and  K  lists.  Use  the  value  of  the 
next  state  Ns  found  in  the  previous  step  as  the  value  of  the  present  state  Ps  for  each 
iteration. 

3.  When  the  lists  of  inputs  are  exhausted,  return  a  list  of  all  the  next  state.  Ns,  values. 
The  Prolog  code  that  accomplishes  this  begins  with  the  boundary  condition  specified 


jksimCCj ,[],_,[]). 
followed  by  the  recursive  procedure 

jksiraC [J 1  Jr] , [K 1 Kr] ,Ps , [Ns  I Nr] )  : - 
jkff(J,.H,Ps,Ks), 
jksim(Jr,Kr,Ns,Nr) . 

■5.S.I  .-I  Flip-Flop  Simulation  Session.  The  Prolog  code  listed  immediately  .above 

and  the  code  that  describes  the  JK  flip-flop's  operational  characteristics  can  be  combined  to 
simulate  the  operation  of  a  single  device.  fully  commented  listing  of  the  code  required  to 
perform  this  simulation  is  given  in  Appendix  B  under  the  file  name  jkcode.pro.  ,Appcmli:\ 
B  also  contains  a  detailed  simulation  session  in  verbose  form.  .A  smaller  and  less  verbose 
extract  of  the  simulation  is  presented  here. 
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Script  VI. 0  session  started  Tue  Sep  10  11:40:29  1991 

Microsoft(R)  MS-DOS(R)  Version  4.01 

(C)Copyright  Microsoft  Corp  1981-1988 

A:\THESIS\CODE>prolog 

+ - + 

I  MS-DOS  Prolog- 1  Version  2.2  | 

I  Copyright  1983  Serial  number:  0001213  I 

I  Expert  Systems  Ltd.  I 

I  Oxford  U.K.  I 

+ - + 

I*  This  command  loads  the  file  which  contains  the  code  necessary  for  this  simulation.  j 

?-  Cjkcode]  . 
jkcode  consulted. 

/*  Starting  with  a  simple  test  case.  */ 

?-  jksim([0] , [0] ,0,Q) . 

Q  =  [0] 

More  (y/n)?  y 
no 

/*  Testing  a  median  case.  */ 

?-  jksim([l] , [0] ,0,Q) . 

Q  =  Cl] 

More  (y/n)?  y 
no 

I*  Testing  an  end  condition.  */ 

?-  jksimCCl] , [1] ,1,Q) . 

d  =  CO] 

More  (y/n)?  y 

no 

j*  Testing  an  input  sequence.  */ 

?-  jksim(Cl,0,l,l,l] , C0,1,1,1,0] ,0,Q) . 

Q  =  Cl, 0,1, 0,1] 
more  (y/n)?  y 
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no 

?-  halt. 

A:\THESIS\CODE>exit 

Script  completed  Tue  Sep  10  11:45:50  1991 

Circuits  that  contain  any  number  of  combinational  devices  and  more  than  one  flip-flop 
can  be  very  difficult  to  accurately  simulate.  The  difficulty  lies  in  the  additional  constraints 
placed  on  the  timing  aspect  of  the  circuit  If  the  proper  signal  is  not  at  the  input  terminals 
of  a  flip-flop  at  the  correct  time,  the  device  could  enter  an  incorrect  state,  resulting  in  an 
erroneous  output.  These  timing  conflicts  are  commonly  referred  to  as  race  conditions.  Race 
conditions  are  avoided  by  using  edge  triggering  devices  or  master-slave  configurations  in 
actual  circuit  implementations.  In  an  actual  circuit,  all  devices  are  triggered  concurrently. 
The  simulation  of  this  concurrent  triggering  action  cannot  be  accomplished  with  Prolog 
because  of  the  sequential  nature  in  which  the  interpreter  e.xecutes  the  goals  of  a  procedure. 

Simulation-Races.  Precautions  must  be  taken  to  avoid  simulation-races  when 
simulating  the  operation  of  comple.x  sequential  circuits  with  Prolog.  The  circuit  shown  in 
Figure  5.3  might  be  improperly  modeled  with  the  following  code: 

jkcrtCC], 

jkcrt([X|Xr] , [YIYr] ,Ps_l,Ps_2, CNs_2|Rest])  :- 
jkff(X,Y,Ps_l,Ns_l), 
jkff (Ns_l,Y,Ps_2,Ns_2) . 

with  the  operation  of  the  JK  flip-flop  specified  by  the  sam.e  set  of  facts  used  in  previous 
examples.  Ps_l  and  Ps  J2  specify  the  present  state  of  the  respective  flip-flop.  If  the  database 

is  queried  with 

?-  jkcrtCCl] , [0] ,0,0,Q) . , 

the  interpreter  will  respond  with 

Q  =  [1] 
more  (Y/N)  y 
no 

Inspection  of  Figure  5.3  shows  that  the  correct  output  for  the  given  query  is  Q  =  [0] .  The 
error  is  due  to  the  simulation-race  that  e,xist,s  between  the  two  devices  of  the  circuit.  Since 
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Figure  5.3.  Sequential  circuit. 


the  operation  of  the  flip-flops  is  simulated  sequentially,  each  device  is  effectively  clocked 
sequentially  instead  of  in  parallel  as  would  be  done  in  an  actual  circuit.  The  simulation 
effectively  “clocked”  the  first  flip-flop,  FF.l,  and  produced  the  resulting  ne.xt  state  Ns_l. 
The  new  value  for  Ns.i  was  passed  on  to  the  second  flip-flop  FF_2,  altering  the  value  on 
its  input  J  terminal  before  the  simulation  had  a  chance  to  “clock”  the  old  value  on  the  J 
terminal  through. 

Simulation-races  can  be  avoided  by  “decoupling”  the  output  terminals  of  the  flip- 
flops  from  any  devices  that  utilize  flip-flop  outputs.  The  simulation  is  allowed  to  proceed 
with  present  state  values  and  the  ne.xt  state  values  are  passed  recursively  on  to  become  the 
ne.xt  simulation’s  present  state  values.  Rewriting  the  code  given  above  for  the  predicate 
jkcrt  to  reflect  this  change  gives 

jkcrt(CX|Xr] , [Y|Yr] ,Ps_l,Ps_2, [Ns_2|Rest] 
jkff(X,Y,Ps_l,Ns_l), 
jkff(Ps_l,Y,Ps.2,Ns_2). 

that  shows  the  altered  relationship  between  input  and  output  values  necessary  to  prevent 
a  simulation-race  from  developing. 

5.4  TTLS  -  A  TTL  Digital  Circuit  Simulator 

The  previously  discussed  methods  of  simulating  the  operation  of  combinational  and 
sequential  digital  circuits  can  now  be  consolidated  to  form  a  general  purpose  simulator. 
Since  most  engineers  have  some  e.xperience  with  standard  transistor-transistor  logic  (TTL) 


.5-13 


design,  a  simple-to-use  TTL  circuit  simulator  can  be  a  very  useful  design  tool.  With  this 
in  mind,  the  Transistor-Transistor  Digital  Logic  Circuit  Simulator  (TTLS)  was  designed. 
TTLS  is  a  pin-level  logic  circuit  simulator  that  can  be  used  to  test  the  performance  of 
digital  circuits  constructed  from  a  restricted  set  of  7400-series  TTL  integrated  circuits. 
The  operation  of  any  TTL  circuit  can  be  simulated  with  TTLS  as  long  as  the  circuit’s 
constituent  integrated  circuits  are  listed  in  the  TTLS  database  file  (ttldata.pro). 

5.4.1  Key  Features  of  TTLS.  TTLS  employs  several  features  that  separate  it  from 
other  reported  digital  circuit  simulators  (31,  36,  41]. 

Stack  Instantiation.  TTLS  uses  “stack-instantiation”  to  unify  variables.  Struc¬ 
tures  with  partially  instantiated  arguments  are  arranged  on  a  Prolog  goal  stack  in  a  man¬ 
ner  that  invokes  a  circuit-rule  defining  the  desired  circuit  operation.  When  the  circuit-rule 
“fires,”  all  uninstantiated  variables  on  the  stack  are  unified.  The  instantiated  structures 
are  removed  from  the  stack  and  reported  to  the  user  as  the  simulation  results.  Stack- 
instantiation  allows  circuit  simulation  to  proceed  at  a  very  quick  pace. 

Memory  Devices.  TTLS  can  be  used  to  simulate  the  operation  of  circuits  that  use 
memory  devices  such  as  flip-flops.  All  memory  devices  are  automatically  cleared  before  a 
simulation  sequence  is  started.  Present  state  and  next  state  values  are  carried  recursively, 
through  the  simulation,  as  arguments.  These  arguments,  as  well  as  other  functions  neces¬ 
sary  to  simulate  a  digital  circuit’s  operation,  are  managed  internally  by  TTLS  and  are  not 
visible  to  the  user. 

Built-in  User  Interface.  TTLS  has  a  built-in  user  interface  that  guides  the  user 
through  the  simulation  process.  The  interface  prompts  the  user  for  any  additional  data 
required  for  the  simulation  to  take  place.  .A.fter  the  initial  simulation  is  completed,  TTLS 
prompts  the  user  either  to  continue  the  simulation  with  a  new  input  sequence  or  to  quit. 

Built-in  Self- Tests.  TTLS  is  written  in  Prolog-1  and  is  designed  to  make  use  of 
Prolog’s  pattern-matching  capabilities.  .Several  key  points  in  the  e.xecution  of  the  simula¬ 
tion  are  tied  directly  to  Prolog’s  ability  to  detect  an  error  if  patterns  should  match  but  do 
not.  For  example,  if  the  user  attempts  to  run  a  simulation  with  a  circuit  requiring  three 
input  values  per  clock  cycle  but  he/she  only  specified  two  values,  the  Prolog  interpreter 
cannot  unify  the  erroneous  input  pattern  and  an  error  message  informs  the  user  of  the 
problem  and  allows  him/her  to  correct  the  mistake. 

The  Prolog  interpreter  also  knows  that  each  integrated  circuit  output  pin  being  used 
must  be  connected  to  input  pins.  The  TTL  data  file  specifies  e.xactly  how  many  input  pins 
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should  correlate  to  an  output  pin  for  a  particular  package.  Although  the  interpreter  never 
explicitly  counts  the  exact  number  of  input  pins  defined  in  the  wire-list  for  each  output 
pin,  it  can  detect  an  input  pin  inadvertently  left  unconnected  (floating).  If  the  interpreter 
does  detect  a  floating  input  pin,  an  error  message  is  generated. 

The  TTLS  Process.  TTLS  derives  a  gate-level  circuit  definition  from  the  user 
provided  input  data  file  and  asserts  the  definition  into  the  database  as  a  fully  executable 
Prolog  circuit-rule.  The  circuit-rule  is  derived  in  an  uninstantiated  form  and  as  such  is 
fully  reuseable.  The  predicate  head  of  the  circuit- rule  is  structured  in  such  a  way  that 
new  simulation  sessions  are  initiated  by  reconfiguring  a  copy  of  the  predicate  head  (called 
a  test-head)  for  each  simulation  clock  cycle,  this  avoiding  the  computational  overhead 
associated  with  redefining  the  circuit-rule  for  each  cycle.  The  structure  of  the  test-head 
allows  related  data,  such  as  input  and  output  values,  to  be  manipulated  as  related  objects 
rather  than  individual  elements.  The  head  is  configured  with  lists  as  arguments  and  has 
the  form 

circuit(ListOfInputValues,ListOfOutputValues,ListOfMeinoryDeviceArgs) ■ 

with  the  functor  “circuit”.  The  first  list,  ListOf  InputValues,  represents  the  input  values 
for  a  particular  clock  cycle.  At  the  start  of  a  simulation  cycle,  the  old  list  of  input  values 
(if  there  is  one)  is  removed  from  the  head  and  the  new  list  of  input  values  is  inserted.  The 
list  of  output  values,  ListOfOutputValues,  enters  into  the  simulation  as  uninstantiated 
arguments  and  after  exposure  to  the  goal  stack,  becomes  fully  instantiated.  When  fully  in¬ 
stantiated,  ListOfOutputValues  contains  one  clock  cycle’s  simulation  results.  The  list  of 
memory  device  arguments,  ListOfMemoryDevicaArgs.  is  invi.sible  to  the  user.  TTLS  auto¬ 
matically  sets  this  list  up  and  manages  it  through  the  simulation  process  in  order  to  prop¬ 
agate  memory  device  state  values  from  one  cycle  to  another.  ListOf MeraoryDeviceArgs 
is  empty  if  there  are  not  any  memory  devices  in  the  circuit.  Manipulating  lists  instead  of 
individual  elements  contributes  to  TTLS'.s  low  e.xocution  time. 

5. 4-^  The  Circuit-File.  In  order  to  initiate  a  simulation  .session,  the  user  must 
provide  an  input  data  file,  referred  to  as  the  circuit-file,  containing  the  following: 

1.  a  wire-list, 

2.  a  list  of  integrated  circuits, 

3.  a  sequence  of  input  values. 

0-1.5 


The  circuit-file  can  be  named  as  the  user  pleases  but  must  end  with  a  “.pro"  extension. 
.A.ny  editor  capable  of  creating  a  file  in  ascii  format  can  be  used  to  create  the  circuit-file. 
Each  of  the  three  constituent  parts  of  a  circuit-file  is  further  described  below. 

The  Wire-List.  The  wire-list  describes  all  of  the  test  circuit’s  inter-  and  intra¬ 
connections,  including  input  and  output  connections.  The  wire-list  must  be  specified  using 
the  following  format; 

Hire_list 

[InputA,dic_miin,dic_pin_num]  , 


[WireNuin,sic_num,sic_pin_nuin,dic_num,dic_pin_num]  , 


COutputNum,sic_nuin,sic_pin_nuin] . 

where  WireNum  is  the  wire  name  expressed  as  a  Prolog  variable.  This  may  be  any  name  the 
user  desires  and  may  be  connected  to  as  many  destination  integrated  circuits  as  desired. 
.4s  a  note  of  caution,  TTLS  will  allow  any  integrated  circuit’s  output  pin  to  be  connected 
to  an  unlimited  number  of  input  pins:  therefore,  it  is  incumbent  on  the  circuit  designer  tu 
avoid  fan-out  problems  when  actually  implementing  a  circuit  simulated  with  TTLS. 

The  source  integrated  circuit  number,  sicjium,  is  a  user-defined  number  for  the  par¬ 
ticular  integrated  circuit  (icl,ic2,...icN).  The  number  sic.pinjium  is  the  source  integrated 
circuit  pin  number  and  is  the  actual  pin  number  of  the  source  integrated  circuit  (siemum) 
to  which  the  wire,  WireNum,  is  connected.  The  other  end  of  WireNum  is  connected  to  the 
destination  integrated  circuit,  dicjium.  at  the  destination  integrated  circuit  pin  numbei 
dic.pinjium  (see  Figure  5.4). 

Input  and  output  connections  are  specified  in  the  format  of  the  first  and  last  wire  JList 
entry  in  the  e.xample  above.  Input  and  output  connections  need  only  a  wire-name,  ex 
pressed  as  a  Prolog  variable,  and  a  destination  integrated  circuit  and  pin  number.  There 
is  no  limit  to  the  number  of  input  or  output  signals  that  can  be  specified.  However,  input 
and  output  signal-wires  must  be  declared  in  a  fashion  that  directly  correlates  the  specified 
input  or  output  value  sequence  to  the  order  of  their  listing  in  the  wire-list.  For  example. 
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WireNum 


Figure  5.4.  Integrated  circuit  connections. 


clock  cycle  1 


Input  C 

Figure  5.5.  Example  of  an  input-sequence. 

if  the  circuit  to  be  simulated  has  three  inputs  A,  B,  and  C,  the  wire-list  would  have  as 
its  first  input  entry,  a  wire-name  of  the  user’s  choice  and  the  integrated  circuit  and  pin 
number  to  which  input  A  is  to  be  connected.  As  many  input  A  entries  as  desired  could 
follow  as  long  as  the  next  distinctly  different  input  entry  is  for  input  B  and  the  associated 
integrated  circuit  to  which  input  B  is  to  be  connected.  Input  B  should  then  be  followed 
by  input  C  and  so  on.  Once  inputs  .4,  B,  and  C  have  been  declared,  additional  A,  B,  or  C 
input  entries  can  come  in  any  order.  The  same  sequential  listing-order  must  be  followed 
for  the  output  signals  (See  Figure  5.5). 

If  the  circuit  design  involves  a  connection  between  ground  or  Vcc  and  an  input  pin 
(for  example  tying  the  “K”  input  to  a  JK  flip-flop  low),  then  the  connection  must  be 
specified.  To  tie  an  input  pin  to  ground  use  a  wire-list  entry  with  the  following  format; 

CO,dic_nuin,dic_pin_nuin]  . 

To  tie  an  input  pin  high  use 

[1  ,dic_num,dic_pin_nuin]  . 

Output  integrated  circuit  pins  that  are  to  be  left  floating  do  not  need  to  be  declared 
in  the  wire-list.  TTLS  will  automatically  ignore  any  floating  output  pins.  Also,  the  user 
should  not  list  connections  to  those  integrated  circuit  pins  that  are  normally  connected  to 
power,  clock,  ground,  clear,  or  preset.  TTLS  will  provide  an  accurate  circuit  simulation 
without  these  connections  being  defined. 
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The  Integrated  Circuit  List.  Each  integrated  circuit  must  be  assigned  a  distinct 
number  (called  an  ic-number).  For  example,  if  the  circuit  contains  two  integrated  circuit 
packages,  both  might  be  declared  as 

ic(icl , ’7400’ ) . 
ic(ic2,’7402’). 

with  the  ic-number  being  assigned  at  the  user's  discretion.  If  the  circuit  requires  se%eral 
integrated  circuit  packages  of  one  type,  a  new  distinct  ic-number  must  be  assigned  to 
each  package.  For  e.xample,  if  the  circuit  requires  six  NAND-gates  (SN7‘}00  has  four  per 
package),  id  would  provide  the  first  four  and  ic2  the  remaining  two.  The  two  integrated 
circuits  would  be  defined  as 

ic(icl,’7400’). 

ic(ic2,’7400’). 

The  Input-Sequence.  .4n  input-sequence  is  defined  as  a  list  of  lists  using  Prolog 
syntax.  For  example,  to  simulate  a  circuit  with  three  inputs,  the  input  list  would  look  like 
Figure  5.5.  The  Figure  shows  that  for  the  first  clock  cycle,  input  A  will  be  set  to  0,  input  B 
will  be  set  to  1,  and  input  C  will  be  set  to  0.  The  pattern  of  one  three  element  list  per  clock 
cycle  can  be  repeated  for  as  many  clock  cycles  as  desired.  Only  one  input-sequence  can  bo 
defined  in  the  circuit-file.  .Additional  input-sequences  can  be  entered  from  the  ke\ board 
during  the  simulation.  .An  input-sequence  can  be  defined  for  an  unlimited  number  of  clock 
cycles  regardless  of  whether  it  is  listed  in  the  circuit-file  or  entered  from  the  keyboard.  .An 
e.xam.ple  of  a  complete  circuit-file  can  be  found  in  Section  5.4.4. 

5.4.3  Detailed  Operational  .Anahjsis.  The  simulation  process  starts  with  the  user 
typing  ‘  ‘  [ttl]".  at  the  Prolog  prompt.  The  built-in  interface  will  respond  by  informing 
the  user  that  several  files  necessary  to  the  program's  execution  are  being  loaded.  The  user 
is  asked  to  specify  the  name  of  the  input  circuit-file,  which  may  be  one  of  the  two  test 
files  provided  or  his  own  personal  file.  TTLS  initiates  a  session  by  reading  the  chosen 
circuit-file. 

Initiating  the  simulation  causes  TTLS  to  form  the  gate-list.  The  procedure  listed 
in  Appendix  B,  called  build.circuit,  does  this  by  scanning  the  wire-list,  ic-number  list, 
and  the  TTL  data  file,  ttldata.pro.  T'tie  gate-list  is  formed  by  matching  output  integrated 
circuit  connections,  found  either  in  the  first  two  entries  of  a  four-entry  wire-list  declaration 
or  an  output  declaration,  with  any  input  connections  found  in  either  the  last  two  entries  of 
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a  four-entry  wire-list  declaration  or  an  input  declaration.  TTLS  also  detects  any  floating 
integrated  circuit  inputs  while  constructing  the  gate-list  and  when  found,  reports  the  ic- 
number  and  the  pin  number  to  the  screen.  The  user  must  correct  the  wire-list  before  the 
simulation  can  proceed.  As  the  final  step,  the  gate-list  is  converted  into  Prolog  e.xecutable 
code  and  asserted  into  the  data  base.  A  copy  of  the  head  of  the  circuit-rule  is  also  asserted 
into  the  data  base  for  later  use  as  a  generic  template.  Asserting  the  circuit-rule  and 
corresponding  head  into  the  data  base  saves  the  computational  overhead  associated  witn 
remanufacturing  the  circuit-rule  for  each  individual  simulation  cycle.  Both  the  circuit-rule 
and  the  head  will  be  reused  an  unlimited  number  of  times.  The  circuit-rule  is  finally 
reported  to  the  user,  providing  a  gate-level  description  of  the  circuit  implementation. 

Following  the  construction  of  the  circuit-rule,  the  procedure  set_up_state  instan¬ 
tiates  each  flip-flop’s  ne.Kt-state  argument.,  to  the  Boolean  value  0.  In  order  to  better 
understand  why  this  step  is  necessary,  a  discussion  of  the  handling  of  present  and  ne.xt 
state  values  for  memory  devices  is  necessary.  A.  definition  of  terminology  is  also  neces¬ 
sary  in  order  to  avoid  confusion  between  a  simulation  sequence  and  a  simulation  cycle. 
The  former  refers  to  the  simulation  of  a  circuit’s  operation  over  the  duration  of  the  cur¬ 
rently  specified  input-value  sequence;  this  process  may  require  many  clock  cycles.  The 
latter  refers  to  the  simulation  of  a  circuit's  operation  for  the  duration  of  one  entry  in  the 
input-value  sequence,  requiring  one  clock  cycle. 

Memory  device  arguments  are  kept  as  a  list  with  the  form 

CQ,QBar,q-t-,QBar+3 

where  Q  is  the  present  state  output  and  QBar  is  the  present  state’s  negation,  (1+  is  the 
future  state  value  and  QBar+  its  negation.  Prior  to  the  start  of  a  normal  simulation  cycle, 
Q  is  instantiated  to  the  Boolean  value  0  or  1  and  QBar  is  instantiated  to  the  complement 
of  Q.  The  variable  Q+  and  its  complement  .are  not  instantiated  until  after  the  simulation 
cycle.  Once  a  cycle  terminates,  Q  and  QBar  arc  no  longer  of  interest  and  are  discarded.  Q+ 
and  QBar-H  now  hold  the  desired  value  of  present  state  for  the  ne.Kt  simulation  cycle,  hence 
Q+  replaces  Q  and  QBar-t-  replaces  QBar.  Q+  and  QBar+  are  replaced  with  variables  that  will 
be  instantiated  during  the  next  simul.uion  cycle. 

Prior  to  the  start  of  a  simulation  sequence,  the  memory  devices  must  be  initialized 
to  a  known  state.  TTLS  clears  all  memory  devices  before  the  beginning  of  each  simulation 
sequence.  This  is  performed  by  the  set.up.state  procedure.  The  procedure  initializes 
each  niemory  device’s  argument-list  by  insunliating  each  list  into  the  following  form; 
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[Q,QBar,0,l] 


The  evaluate.circuit  procedure  will  shift  the  Q+  and  QBar+  values  into  the  Q  and  QBar 
positions,  placing  each  memory  device  into  a  known  starting  state.  Once  this  process  is 
performed  for  each  memory  device  in  the  circuit,  the  simulation  can  proceed.  If  the  circuit's 
composition  is  purely  combinational,  the  list  of  memory  device  arguments  is  empty  and 
this  preparation  is  not  performed. 

Following  the  preparation  of  the  memory-device  argument-list,  the  first  simulation 
cycle  is  ready  to  begin.  The  procedure  evaluate.circuit  receives  the  input  sequence  value 
list,  the  memory  device  argument  list,  and  a  clock  cycle  count  of  0.  The  memory  device 
argument  list  is  manipulated  as  discussed  above  by  the  procedure  update^tates.  The 
transfer  of  state  values  is  done  at  this  level  as  evaluate.circuit  recursively  calls  itself  each 
simulation  cycle  until  the  simulation  sequence  is  complete.  A  copy  of  the  circuit-rule  head 
is  also  retrieved  from  the  data  base  to  serve  as  a  structural  template.  The  retrieved  head  is 
procedurally  correct  with  the  proper  functor  and  arity  necessary  to  invoke  the  circuit-rule. 
However,  all  arguments  of  the  copy  are  uninstantiated.  The  list  of  input  values  for  the 
simulation  cycle  and  the  list  of  memory  device  arguments  must  be  instantiated  before  the 
circuit-rule  is  invoked.  This  is  done  ir  one  step  using  the  built  in  operator  univ.  Univ  is  a 
built-in  procedure  that  provides  a  useful  way  to  obtain  the  arguments  of  a  structure.  The 
syntactical  representation  for  univ  is  “  =  The  e.Kpression  X  =.  .L  means  that  L  is  the 
list  whose  head  is  the  functor  X,  and  whose  tail  is  the  list  of  arguments  of  X.  If  a  segment 
of  code  states 


X=..Cfoo,A,B,C] 

then  X  would  be  instantiated  to  the  functor  foo  with  arguments  A,B  and  C. 

Using  univ,  the  uninstantiated  list  of  input  values  is  replaced  with  the  head  of  the 
input-sequence  list  and  in  the  same  step,  the  list  of  memory  device  arguments  is  replaced 
with  the  updated  version  supplied  by  update_states.  The  list  that  holds  the  uninstanti- 
ated  output  arguments  is  left  alone.  The  simulation  cycle  is  now  ready  to  proceed. 

The  fully  prepared  head  is  now  sent  to  the  procedure  test.circuit  as  a  Prolog 
goal.  Since  the  head  is  procedurally  correct,  it  can  be  used  to  invoke  the  circuit-rulc. 
Through  the  process  of  stack  instantiation,  all  of  the  uninstantiated  variables  in  the  output 
argument  list  and  the  list  of  memory  device  arguments  are  fi.xed.  Both  of  these  lists  are 
returned  to  evaluate-circuit  where  the  clock-cycle  count  is  incremented,  the  list  of 
output  values  reported  to  the  user,  and  the  list  of  memory  device  arguments  prepared  for 
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the  next  simulation -cycle.  This  process  continues  until  the  list  of  input  sequence  values  is 
exhausted. 

The  built-in  TTLS  user  interface  now  asks  the  user  if  additional  input  sequence  trials 
are  desired.  If  so,  the  memory  devices  are  cleared  and  the  new  input  sequence  is  applied  to 
the  previously  defined  circuit-rule.  If  the  input  sequence  is  not  provided  in  the  proper  form 
(if,  for  example,  the  c.  :uit  requires  three  input  sequence  values  to  be  specified  and  the 
user  erroneously  provides  only  two),  the  head  will  not  take  on  the  correct  format  and  the 
simulator  will  not  be  able  to  invoke  the  circuit-rule.  If  this  happens,  the  interface  informs 
the  user  of  the  problem  and  allows  the  user  to  either  fix  the  error  or  terminate  the  session. 
-A.  complete  listing  of  the  simulator  code  is  given  in  -Appendix  B. 

•5.-/.-/  TTLS  Combinational  Circuit  Example.  The  following  code  constitutes  a  com¬ 
plete  circuit-file  that  describes  a  full-adder  and  all  the  code  necessary  to  simulate  its  op¬ 
eration. 


wire.list  ClnputA,icl,pin2] , 
ClnputB,icl,pin3] , 

CinputC ,  id  ,pin8]  , 
ClnputA,ic2,pinl] , 
ClnputB,ic2,pin2] , 
ClnputC,ic2,pin4] , 
CWl,icl,pinl,icl,pin5] , 
CW2,ic2,pin3,icl,pin6] , 
CW2,ic2,pin3,ic3,pin2] , 
CW3,icl,pin4,icl,pin9] , 
CW3,icl,pin4,ic2,pin5] , 
CW4 ,  id  ,pinlO ,  id  ,pinl2]  , 
CW5,ic2,pin6,id,pinl3]  , 
[W5,ic2,pin6,ic3,pinl] , 
[Suin,id,pinl4]  , 

[Carry ,ic3,pin3] . 


ic(id,’7402’). 
ic(ic2,'7408’). 
ic(ic3, ’7432’)  . 
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u.t.tc  1  ii'.  1  ].j!  Ilf  tiljl-ilj 


input_sequence(C [0,0,0] , [0,0,1] , [0,1,0] , [0, 1, l] , [i ,0,0] , 

[1,0,1], [1,1,0], [1,1,1]]). 

An  ic-package  level  diagram  of  the  circuit  described  by  the  wire-list  is  shown  in  Figure  5.6. 
Figure  5.7  depicts  the  gate-level  representation  of  the  same  circuit  with  the  interconnecting 
wires  labeled  with  the  wire-names  from  the  wire-list.  Figure  5.8  shows  the  same  gate-level 
circuit  but  note  that  the  wire-names  have  been  replaced  with  the  Prolog  assigned  variable 
names.  Comments  added  to  the  circuit-file  and  the  simulation  session  are  set  off  with  the 
Prolog  comment  syntax  /* 

Script  VI. 0  session  started  Thu  Nov  14  23:19:15  1991 

+ - + 

I  MS-DOS  Prolog-1  Version  2.2  I 

I  Copyright  1983  Serial  number:  0001213  I 

I  Expert  Systems  Ltd.  I 

I  Oxford  U.K.  I 

+ - + 

/*  starting  the  session.*/ 

?-  [ttl]. 

Loading  TTLSIH.PRO. 

Loading  TTLDATA.PRO. 

Loading  SETUP. PRO 

Type  ’go’  at  the  next  prompt  to  start  the  process. 

Be  sure  to  end  all  commands  with  a  period. 

ttl  consulted. 

?-  go. 

Two  demonstration  files  are  provided  with 

this  simulator.  The  first,  CKTl.PRO,  describes  a  full-adder. 

The  second,  CKT2. PRO, describes  a  pattern-detector  which 
generates  an  output  (1)  each  time  the  input  stream  has  at  least 
two  zeros  followed  by  an  odd  number  of  ones. 

If  you  want  to  simulate  your  own  circuit  file; 
type  the  file  name  at  the  prompt.  Your  file 
must  have  the  form  ’filename. pro’  but  type  only 
the  file  name  at  the  prompt.  You  may  return  to  dos 
at  any  time  by  typing  ’halt.’  at  the  prolog  prompt. 

Which  file  would  you  like  to  simulate?  >  (cktl./ckt2./YourFile) 
cktl. 

Loading  CKTl.PRO 

/*  The  wire-list  is  repeated  for  the  convenience  of  the  user.*/ 
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The  wire  list  is: 

[_117,icl,pin2] 

[_127,icl,pin3] 

C_137,icl,pin8] 

[_117,ic2,pinl] 

C_127,ic2,pin2] 

C_137,ic2,pin4] 

[_177 ,  id  ,pinl ,  id  ,pin5] 

[_  191 ,  ic2  ,pin3 ,  id  ,pin6] 
[_191 , ic2 ,pin3 , ic3 ,pin2] 
C_219,id  ,piii4,id,pin93 
[_2i9 ,  id  ,pin4,  ic2  ,pin53 
[_247 ,  id  ,pinlO ,  id  ,pinl23 
C_26l,ic2,pin6,id,pinl3] 
C_261 , ic2 ,pin6 , ic3 ,pinl] 
[_289,id  ,pinl4] 
C_299,ic3,pin3] 


/*  This  is  the  gate-level  circuit  description  which  the  interpreter  derives  from  the  wire-list. 
Note  how  much  easier  this  list  is  to  understand  compared  to  the  original  wire-list.  */ 


The  gate  level  circuit  is: 
nor(_ll7,_127,_177) 
and(_ll7,_127,_191) 
nor(_177,_191,_219) 
nor(_137,_2i9,_247) 
and(_137,_2l9,_261) 
nor(_247,_26l,_289) 
or(_261,_191,_299) 

/*  The  input  and  output  values  are  printed  to  the  screen  and  referenced  to  their  particular 
clock  cycle.  */ 
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CLOCK  CYCLE 

INPUT  VALUES 

OUTPUT  VALUES 

1 

[0,0,0] 

[0.0] 

2 

[0,0,1] 

[1.0] 

3 

[0,1,0] 

[1.0] 

4 

[0,1,1] 

[0,1] 

5 

[1.0,0] 

[1.0] 

6 

[1,0,1] 

[0.1] 

7 

[1.1.0] 

[0,1] 

8 

[1.1.1] 

[1,1] 

Do  you  want  to  input  another  simulation  sequence?  (yes./no.)> 
no. 

simulation  over 

Script  completed  Thu  Nov  14  23:20:07  1991 


5.v/.5  TTLS  Sequential  Ciraiit  Example.  This  example  illustrates  the  simulation 
of  a  sequential  circuit  pattern-detector  that  when  provided  an  input  sequence  of  Boolean 
values  0  or  1,  detects  the  occurrence  of  two  or  more  O’s  followed  by  an  odd  number  of 
Vs.  Derivation  of  the  pattern-detector  circuit  is  described  in  Appendix  B.  The  complete 
circuit-file  is 


wire.list  :- 

ClnputA,icl,pinl] , 
ClnputA,ic2,pinl] , 
ClnputA,ic3,pin9] , 
[Wl,icl,pin2.ic3,pinl] , 
[Wl , id  ,pin2,ic2,pin4]  , 
C'.Jl , id ,pin2,ic4,pinl3] , 
CW2,ic3,pin3,ic4,pin2j , 
CW3,ic4,pinlO,ic3,pin2] , 
CW3,ic4,pinlO,ic2,pin2] , 
[W3,ic4,pinl0,ic3,pin4] , 
CW4,ic4,pin6,ic2,pin53 , 
CW4,ic4,pin6,ic3,pin5] , 
CW5,ic2,pin3,ic4,pin3] , 
CW6,ic2,pin6,ic4,pinl4] , 
[W7,ic3,pin6,ic3,pinl0] , 
[Output , ic3 ,pin8] . 


0-2.5 


InputA 

InputB 
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Full-adder 


Figure  5.7.  Gate-level  diagram  of  a  full-adder  with  wit 


_137 

-117 

_127 


r=FO 


_177 


219 


.261 


Full-adder 


Figure  5.8.  Gate-level  diagram  of  a  fu 
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Figure  5.9.  Integrated  circuit  diagram  of  a  pattern-detector. 

input_sequence( CCl] , [0] , [0] , [0] , [1] , [l] , [1] ,[!]]). 

ic(icl,’7404’). 
ic(ic2,’7432’). 
ic(ic3, ’7408’) . 
ic(ic4, ’74109’). 

The  TTL  package  level  diagram  is  shown  in  Figure  5.9.  The  gate-level  circuit  dia¬ 
grams  showing  both  the  user  provided  wire  names  and  the  Prolog  assigned  variable  wire- 
names  are  given  in  Figures  5.10  and  5.11. 

Script  VI. 0  session  started  Fri  Nov  15  00:53:23  1991 


+ - - - + 

I  MS-DOS  Prolog- 1  Version  2.2  I 

I  Copyright  1983  Serial  number:  0001213  I 

I  Expert  Systems  Ltd.  I 

I  Oxford  U.K.  I 

+ - + 


?-  Cttl]. 
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Figure  5.10.  Gate-level  diagram  of  the  pattern-detector  circuit  with  wire-names. 


Figure  5.11.  Gate-level  diagram  of  the  pattern-detector  circuit  with  variable  wire-names. 
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Loading  TTLSIH.PRO. 

Loading  TTLDATA.PRO. 

Loading  SETUP. PRO 

Type  'go’  at  the  next  prompt  to  start  the  process. 

Be  sure  to  end  all  commands  with  a  period. 

ttl  consulted. 

?-  go. 

Two  demonstration  files  are  provided  with 

this  simulator.  The  first,  CKTl.PRO,  describes  a  full-adder. 

The  second,  CKT2. PRO, describes  a  pattern-detector  which 
generates  an  output  (1)  each  time  the  input  stream  has  at  least 
two  zeros  followed  by  an  odd  number  of  ones. 

If  you  want  to  simulate  your  own  circuit  file; 
type  the  file  name  at  the  prompt.  Your  file 
must  have  the  form  ’filename. pro’  but  type  only 
the  file  name  at  the  prompt.  You  may  return  to  dos 
at  any  time  by  typing  ’halt.’  at  the  prolog  prompt. 

Which  file  would  you  like  to  simulate?  >  (cktl ./ckt2./YourFile) 
ckt2. 

Loading  CKT2.PR0 

/*  The  wire-list  is  printed  to  the  screen  for  the  user’s  convenience. 


The  wire  list  is; 

C_117,icl,pinl] 

[_117,ic2,pinl] 

[_ll7,ic3,pin93 
[_147,icl ,pin2,ic3,pinl] 

C_147,icl ,pin2,ic2,pin4] 

C_147,icl ,pin2, ic4,pinl3] 

[_ 189 , ic3 , pin3 , ic4 ,pin2] 

C_203,ic4,pinl0,ic3,pin23 
C_203 , ic4 ,pinlO , ic2 ,pin2] 

C_203 , ic4 ,pinlO , ic3 ,pin4] 

C_245 , ic4 ,pin6 , ic2 ,pin5] 

C_245 , ic4 , pin6 , ic3 , pin5] 

C_273 , ic2 ,pin3 , ic4 ,pin3] 

C_287 , ic2 ,pin6 , ic4 ,pinl4] 

C_301 , ic3 ,pin6 , ic3 ,pinlO] 

C_315,ic3,pin8] 

/*  This  is  the  gate-level  circuit  which  the  interpreter  derived  from  the  input  wire-list.  *  j 
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The  gate  level  circuit  is: 
inv(_117,_147) 
and(_147,_203,_189) 

jkbarC  C.287 , _147] ,  [.203 , _841] , L851 , _853] ) 

jkbar(C_189,_273] , C_245,_966] , [_976,_978]  ) 

or(_117,_203,_273) 

or(_147._245,_287) 

and(_203,_245,_301) 

and(_117,_301,_315) 

/*  The  sequence  of  input  and  output  values  are  correlated  to  clock  cycles  for  the  conve¬ 
nience  of  the  user.  */ 


CLOCK  CYCLE 

INPUT  VALUES 

OUTPUT  VALUES 

1 

Cl] 

CO] 

2 

CO] 

CO] 

3 

[0] 

CO] 

4 

CO] 

•  CO] 

5 

Cl] 

Cl] 

6 

Cl] 

o 

1— J 

7 

1 — 1 

Cl] 

8 

Cl] 

Co] 

/*  Another  test  sequence  of  input  values  is  entered  from  the  keyboard.  */ 


Do  you  want  to  input  another  simulation  sequence?  (yes./no.)> 
yes . 

Please  enter  the  new  sequence  as  a  list  of  lists. 

One  sublist  should  be  entered  for  each  simulation 
clock  cycle  desired.  Each  sublist  should  contain 
the  correct  number  of  input  values .  Only  the 
boolean  values  0  or  1  may  be  entered. 

Enter  your  input  now.  Do  not  forget  to 
to  follow  your  entry  with  a  period. 

CCi] ,  Cl] ,  Cl] ,  CO] ,  CO] .  CO] ,  CO] .  Cl] . Cl]] . 
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CLOCK  CYCLE 

INPUT  VALUES 

OUTPUT  VALUES 

1 

Cl] 

CO] 

2 

Cl] 

CO] 

3 

Cl] 

CO] 

4 

CO] 

CO] 

5 

CO] 

CO] 

6 

CO] 

CO] 

7 

CO] 

CO] 

8 

Cl] 

Cl] 

9 

Cl] 

CO] 

Do  you  want  to  input  another  simulation 
sequence?  (yes./  no.)  >yes. 

Please  enter  the  new  sequence  as  a  list  of  lists. 
One  sublist  should  be  entered  for  each  simulation 
clock  cycle  desired.  Each  sublist  should  contain 
the  correct  number  of  input  values.  Only  the 
boolean  values  0  or  1  may  be  entered. 

Enter  your  input  now.  Do  not  forget  to 
to  follow  your  entry  with  a  period. 


/*Intentionally  putting  an  incorrectly  formatted  input-  sequence  in.  *  j 
Cl].Cl].[l]. 

/*This  header  print-out  can  be  fi.'ced  so  that  it  does  not  show  up  if  an  erroneous  input 
sequence  is  entered.  */ 

CLOCK  CYCLE  INPUT  VALUES  OUTPUT  VALUES 

ERROR:  You  did  not  enter  your  new  input  sequence 
list  in  the  proper  format.  Enter  the  correct  form 
of  the  input  sequence. 

Do  you  want  to  try  again?  (yes. /no.) 
no. 

simulation  over 


5.5  The  Simulation  of  Circuit  Faults 

Prolog  can  be  used  to  identify  faulty  components  by  altering  a  circuit's  operation  In 
order  to  mimic  improper  operation.  Components  that  are  suspect  need  only  be  labeled  a.', 
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such  and  their  operating  characteristics  altered  to  reflect  the  symptoms  of  the  malfunction. 
For  e.xample,  the  circuit  shown  in  Figure  5.12,  when  operating  correctly,  performs  the  XOR- 
gate  function.  If  the  circuit  malfunctioned  and  the  output  was  observed  cis  that  listed  in 
Table  5.4,  under  the  column  labeled  “Out",  the  circuit’s  operation  could  be  simulated 
with  faulty  gates  until  the  simulated  operation  mimics  the  observed  faulty  operation.  One 
possible  problem  that  would  cause  the  symptoms  could  be  the  first  N.4ND-gate  of  the 
circuit  stuck  at  the  logic  value  “1".  Figure  5.12  shows  Uie  suspect  gate  labeled.  Suppose 
the  Prolog  definition  of  the  circuit  to  be  altered  so  that  the  goal-entry  for  that  particular 
gate  is  replaced  by  the  goal 

sa_l(X,Y,Tl) 

and  the  operation  for  the  function  sa_l  is  defined  as  in  Table  5.5.  The  simulated  output 
of  the  circuit  would  then  mimic  the  observed  symptoms.  One  possibility  to  correct  the 
malfunction  would  be  to  replace  that  NAND-gate. 

This  is  a  very  simplistic  e.xample  but,  through  the  use  of  hierarchical  descriptions, 
comple.x  circuits  can  be  troubleshot,  module  by  module,  until  the  faulty  component  is 
isolated. 
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Table  5.4.  Truth-table  for  Figure  5.12  with  the  first  .\.4ND-gate  -‘stuck  at  1 


X 

Y 

T1 

Out 

0 

0 

1 

0 

0 

1 

1 

1 

1 

0 

1 

1 

1 

1 

1 

1 

Table  5.5.  Truth-table  for  a  .N\4ND-gate  “stuck  at  1”. 


X 

Y  i 

Out 

0 

0  1 

1 

0 

1 

1 

1 

0  i 

1 

1 

1  1 

1 

VI.  Specialization 


6. 1  Introduction 

The  thrust  of  this  chapter  is  to  provide  a  Prolog  implementation  of  the  specialization 
process  described  by  Clocksin  [13,  l-l].  An  extensive  review  of  published  literature,  going 
back  to  the  original  publication  of  Clocksin’s  article  in  1986,  could  uncover  no  further 
mention  of  the  process.  Clocksin  outlined  a  specific  example  in  his  article  on  specialization 
[14]  in  order  to  illustrate  the  process,  along  with  an  algorithm  that  is  very  dependent  upon 
his  example.  His  description  of  specialization  is  very  general  in  his  example.  Nowhere  in 
his  article  does  he  give  any  details  concerning  implementation. 

6.2  Description  of  the  Problem 

Very  Large  Scale  Integrated  (VLSI)  Circuits  are  often  designed  with  predefined 
generic  circuits  called  standard  cells.  Circuits  designed  with  standard  cells  tend  to  contain 
more  devices  than  circuits  that  are  built  from  basic  components  because  of  two  reasons: 

1.  Standard  cells  need  standard  interfaces.  Each  connection  between  a  cell  and  other 
cells  must  have  some  form  of  internal  matching  interface. 

2.  Standard  cell  libraries  provide  a  manageable  number  of  general-purpose  cells.  Since 
the  standard  cell  designer  cannot  predict  in  advance  the  precise  functionality  required 
by  some  future  designer,  over-designed  cells  are  usually  produced. 

.After  the  design  of  a  VLSI  circuit  has  been  completed,  it  is  desirable  to  remove  any 
extraneous  circuitry.  The  Prolog  code  described  in  this  chapter  will  remove  all  circuitry 
that  does  not  directly  contribute  to  the  final  output  of  the  circuit.  Redundant  components 
are  removed  by  tracing  through  the  circuit's  hierarchy  and  identifying  any  components 
that  have  unused  outputs.  A  component  that  has  all  of  its  outputs  unused  can  be  removed 
with  impunity.  This  removal  may  lead  to  the  removal  of  other  components  within  the 
circuit.  This  entire  process  has  been  named  specialization  by  Clocksin. 

.An  implementation  of  Clocksin's  process  of  specialization  is  given  in  this  chapter.  The 
key  to  understanding  this  implementation  lies  in  understanding  the  recursive  properties 
of  Prolog.  As  the  interpreter  proceeds  through  the  levels  of  recursion,  its  inherent  search 
strategy  enables  it  automatically  to  keep  track  of  where  it  has  been.  This  allows  the 
various  levels  of  abstraction  to  be  properly  di.*)assembled  and  reassembled  as  the  interpreter 
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moves  through  a  circuit’s  hierarchy.  The  programmer  needs  only  to  define  the  upper 
level  of  a  circuit's  nodal  structure  and  provide  the  constituent  lower-level  generic  module 
templates.  The  interpreter  will  make  the  appropriate  unifications  and  instantiations  during 
the  execution  of  the  program. 

Inverters,  N.-lND,  .\ND,  XOR,  and  OR-gates  are  considered  to  be  primitive  through¬ 
out  this  chapter.  The  investigation  into  Clocksin's  process  discussed  in  this  chapter  will 
be  confined  to  combinational  circuits. 

6.3  Clocksin’s  Specialization  Example 

The  circuit  Clocksin  specialized  is  shown  in  Figure  6.1.  By  convention,  the  circuit 
to  be  specialized  must  have  one  or  more  used  input  nodes  and  one  or  more  used  output 
nodes.  Only  the  submodules  of  the  circuit  to  be  specialized  are  allowed  to  have  entirely 
unused  sets  of  output  nodes.  Note  that  one  of  the  output  nodes,  Co,  specified  as  part  of 
the  submodule  M2,  is  unused.  Given  the  top-level  goal  of  specializing  the  two-bit  adder- 
subtractor,  defined  as 

twobit(al,bl,a2,b2,c,as,sl,s2) 
the  program  proceeds  as  follows: 

1.  Inspect  the  modules  of  the  two-bit  adder-subtractor,  finding  the  one-bit  adder- 
subtractor  M2  (see  Figure  6.1)  with  an  unused  output  node,  Co.  Recursively  enter 
the  definition  of  M2  with  the  goal  of  further  investigating  it. 

2.  Tracing  the  unused  output  node,  Co,  of  M2  leads  to  the  OR-gate,  Gl,  as  shown  in 
Figure  6.2.  Since  M2’s  output  is  not  used  elsewhere  and  an  OR-gate  is  defined  as  a 
primitive  gate,  it  can  be  removed.  Removing  OR-gate  Gl  leaves  the  AND-gate  G2 
and  the  XOR-gate  G3  with  unused  output  nodes  that  can  also  be  removed  as  neither 
of  their  outputs  are  used  elsewhere.  The  half-adder  M4  (see  Figure  6.3)  now  has  an 
unused  output  node  Tl;  hence  it  is  entered  recursively  with  the  goal  of  specializing 
it.  Note  that  the  internal  connection,  Tl.  is  hidden  from  the  definition  of  twobit. 

3.  Two  gates  can  be  removed  from  the  half-adder  M4.  Both  the  Inverter  G4  and  the 
N.AND-gate  Go  are  not  needed  (see  Figure  6.3).  No  other  gates  or  modules  with 
unused  outputs  remain  in  the  half-adder  M4  so  a  unique  identifier  for  the  specialized 
half-adder  is  generated  and  M4’3  refined  definition  is  entered  into  the  database.  The 
new  module  replaces  the  half-adder  M4  (see  Figure  6.4).  Control  then  returns  to  the 
next  higher  level  in  the  circuit  hierarchy. 
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M4 


M5 
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G2 


e> 


one-bit 

adder/  subtracter 


Co 


Figure  6.2.  Circuit  schematic  for  a  one-bit  adder-subtractor. 


4.  The  remaining  half-adder,  M5,  of  the  one-bit  adder-subtractor,  M2,  also  has  an 
unused  output  node  as  shown  in  Figure  6.2.  Because  of  this,  the  definition  of  modulo 
M5  is  now  entered  with  the  goal  of  specializing  it.  .\s  was  previously  done  for  '.ho 
half-adder  module  M4,  the  module  M-5  is  reduced  to  the  circuit  of  Figure  6.4  a^.d  a 
unique  identifier  generated  for  the  new  version.  The  new  version  (Figure  6.4/  is  aUo 
added  to  the  database  and  control  now  returns  back  to  the  ne.xt  higher  level  of  the 
circuit  hierarchy,  that  of  the  one-bit  adder-subtractor.  All  possible  specializations 
have  been  carried  out  at  this  level:  therefore  control  returns  to  the  two-bit  adder- 
subtractor  level. 


-5.  The  two-bit  adder-subtractor  module  M2  is  replaced  by  its  specialized  ver-sion  i  Fig¬ 
ure  6.5)  and  the  search  terminates  because  all  unused  outputs  at  every  level  Iuiva 
been  investigated.  The  final  hierarchical  repre-sentation  of  the  circuit  is  shown  in 
Figure  6.6. 
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6.J,  The  Development  of  the  Specialization  Code 

This  chapter  introduces  a  procedure  developed  for  the  specialization  of  a  more  gen¬ 
eral  class  of  circuits  than  that  represented  by  Clocksin’s  example.  A  more  general  approach 
must  be  capable  of  handling  four  types  of  situations  relating  to  specialization; 

1.  Primitive  modules  that  have  at  least  one  used  output  node  cannot  be  specialized. 

2.  If  all  the  output-nodes  of  a  higher-level  module  are  used,  then  that  module  cannot 
be  specialized. 

3.  If  all  output-nodes  of  a  primitive  module  are  unused,  then  that  module  should  be 
removed  from  the  circuit.  This  removal  may  result  in  disconnecting  the  output  nodes 
of  other  primitive  or  higher-level  modules.  These  modules  may  also  be  able  to  be 
rem.oved. 

4.  If  a  higher-level  module  has  some,  but  not  all  of  its  output-nodes  unused,  it  is  nec¬ 
essary  to  recursively  descend  the  modules  hierarchy  to  determine  if  any  submodules 
can  be  removed. 
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Figure  6.6.  Specialized  version  of  the  two-bit  adder-subtractor. 
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The  Code.  In  order  for  Clocksin’s  specialization  process  to  work,  the  user  must 
specify  a  circuit  definition  at  the  highest  level,  any  submodule  definitions,  the  direction  of 
submodule  ports,  and  gate  status.  Gate  status  is  declared  e.Kplicitly  with  the  primitive 
predicate  explained  earlier  in  Chapter  4.  The  direction  of  submodule  ports  is  declared 
with  a  generic  ['dedicate.  The  general  form  of  the  declaration  is 

direction(GateType,InputPorts,OutputPorts) . 

For  example,  the  fact  direction(nand(A,B,C) ,  [A.B] ,  [C] )  declares  thai  any  .XAND-gate 
fact  of  arity  three  that  can  be  found  has  three  ports.  The  first  two  arguments  define  input 
ports  and  the  third  argument  defines  an  output  port. 

The  direction  of  the  ports  must  be  declared  for  any  submodule  but  not  for  the  upper 
level  definition  of  the  circuit  to  be  specialized.  Consider  the  circuit  defined  in  Clocksin's 
specialization  example  (13].  The  circuit  definition  is 

twobit(Al,B2,Al,B2,C,As,Sl,S2) 
addsub(Al,Bl,C,As,Sl,T) , 
addsub(A2,B2,T,As ,S2,Z) . 

The  upper-level  circuit,  twobit,  does  not  need  a  fact  that  describes  the  direction  of  its 
ports.  The  direction  of  twobit’s  ports  is  determined  automatically  during  the  e.xecution  of 
the  process  that  «pecializes  twobit.  The  direction  of  twobit  is  asserted  into  the  database 
for  future  use.  This  is  an  additional  feature  that  Clocksin  mentioned  but  said  he  did  not 
provide  in  his  implementat'on  of  the  process.  Submodules  under  twobit  must  have  their 
port  directions  declared,  ne  specialization  of  twobit  requires  direction  declarations  for 
addsub  which,  in  turn,  requires  declarations  of  direction  for  its  submodules  and  so  on  until 
the  primitive  level  of  the  hierarchy  is  reached.  A  complete  listing  of  the  definition  of  twobit 
and  the  ancillary  procedures  required  to  specialize  twobit  can  be  found  in  .A.ppendix  C. 
.Section  C.1..5,  under  the  code  for  test4. 

.-Vppendix  C  also  contains  test  example.s  besides  the  one  for  twobit.  Four  test  ca.sGs 
are  considered,  including  twobit,  in  order  to  illustrate  the  specialization  process  as  it  oper¬ 
ates  at  the  various  levels  of  circuit  hierarchy.  The  purpose  of  each  test  case  i.s  documented. 
“Bef'-re"  and  “after”  schematic  representations  are  provided  along  with  verbose  simulation 
sessions  that  allow  the  e.xecution  of  the  process  to  be  followed  in  detail. 

The  execution  of  the  specialization  code  given  in  .A.ppendix  C,  regardless  of  the  circuit 
to  be  specialized,  starts  with  an  invoking  call  to  the  procedure  scan(Head).  The  variable 


Head  is  the  definition  of  the  circuit  to  be  specialized.  No  variables  can  appear  in  the  circuit 
definition  at  this  level.  For  e.xample.  the  two-bit  adder-subtractor  of  Figure  6.1  is  described 
as  two-bit(al,bl,a2,b2,c,as,sl,s2).  No  unused  outputs  are  allowed  to  appear  in  the 
circuit  definition  at  this  level;  therefore  if  there  are  any  any  unused  outputs,  they  must 
appear  at  some  lower  level  in  the  hierarchy.  The  top  level  circuit  definition  is  broken  down 
into  a  head  predicate  and  the  body  goals.  Each  goal  of  the  body  represents  one  module, 
that  can  be  either  primitive  or  higher-level.  The  head  arguments  are  checked  against 
the  goal  arguments  in  order  to  detect  any  unused  output  nodes.  A  list  of  the  goals  and 
any  unmatched  nodes  are  passed  to  the  analyzeCGoals ,Acc, Circuit)  procedure.  The 
procedure  analyze  e.xamines  each  of  the  goals  and  separates  those  goals  with  unused  output 
nodes  from  those  with  no  unused  output  nodes.  If  a  goal  does  not  have  any  unused  output 
nodes,  it  is  stored  in  the  accumulator  (Acc)  for  future  use.  If  there  are  no  unused  output 
nodes  found  after  e.xamining  all  the  goals,  the  original  circuit  definition  is  returned  to  the 
scan  procedure  via  the  variable  Circuit  and  the  process  terminates  without  changing  the 
original  circuit  definition. 

If  a  goal  is  found  that  has  at  least  one  unused  output,  the  goal  is  sent  to  another 
procedure  called  specialize.  If  the  goal  is  primitive,  it  is  removed  from  the  circuit's 
definition  and  the  list  of  unused  nodes  is  updated  accordingly.  When  a  module  is  identified 
as  being  removable,  its  input  nodes  must  be  tested  to  deteimine  if  they  can  be  considered 
extraneous  to  the  circuit.  A  simple  test  is  used  to  determine  if  a  module's  input  nodes  can 
be  added  to  the  list  of  unmatched  nodes  once  that  module  has  been  removed.  Basically,  if 
there  is  no  other  requirement  6  a  input  node  designator  throughout  the  circuit  at  an> 
level,  then  tha.  input  node  can  '  added  to  the  list  of  unmatched  nodes. 

If  specialize  receives  a  higher-level  module  from  analyze,  then  the  definition  of 
the  module  is  recursively  entered  by  resubmitting  it  to  analyze,  receiving  the  specialized 
version  back,  updating  the  list  of  unmatched  nodes,  and  returning  control  back  to  the  orig¬ 
inal  invoking  call.  Analyze  re-examines  the  accumulator  each  time  a  module  is  specializc>d 
to  ensure  that  all  possible  redundant  connections  are  identified.  Once  the  accumulatoi 
contains  only  those  modules  that  cannot  be  further  reduced,  a  new  unique  identifier  is 
generated  and  asserted  into  the  database.  The  direction  of  the  new  module  is  also  de¬ 
termined  and  asserted  into  the  database.  .\Ithough  there  is  no  direct  use  for  this  featuie 
currently,  future  implementations  or  applications  of  this  procedure  may  find  it  convenient. 

Control  then  returns  to  the  next  level  up  until  control  finally  reverts  to  the  topmost 
level  where  the  results  of  the  process  are  displayed  on  the  screen.  The  final  circuit  i.-. 


expressed  as  a  hierarchy  of  modified  modules.  The  composition  of  any  module  can  be 
found  if  the  built-in  procedure  listing(X)  (where  X  is  the  functor  of  the  desired  module) 
is  used. 

6.4-1  -d  Specialization  Session.  Appendi,\  C  contains  the  specialization  code 
(speccode.pro)  and  four  verbose  test  sessions.  The  sessions  are  verbose  so  the  reader 
can  easily  follow  the  execution  of  the  program.  The  last  test,  test4  is  repeated  here  in 
nonverbose  form.  Comments,  that  were  added  to  improve  the  clarity  of  the  session,  are 
set-off  with  the  standard  Prolog!  syntax  for  comments  /*. .  .*/. 

/*test4  circuit  definition.*/ 
test4 

scan(twobit(al,bi,a2,b2,c,as,sl,s2)) . 


tHobit(Al,Bl,A2,B2,C,As,Sl,S2) 
addsub(Al,Bl,C,As,Sl,T), 
addsub(A2, B2,T, As, S2, Unused) . 

/*The  following  submodule  definitions  are  neces.sary  to  carry  out  test4.  Section  C.I.5 
further  explains  the  following  procedures.  **/ 

addsub(A,B,C,As,S,Co) 
halfadd(B,C,Tl,T2), 
halfadd(A,Tl,S, Unused) , 
xor_gate(A,As ,T3) , 
and_gate(Tl,T3,T4) , 
or_gate(T2,T4,Co) . 


haifadd(A,B,S,C) 
xor_gate(A,B,S) , 
nand_gate(A,B,T) , 
nnot_gate(T,C) . 
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direct ion(addsub(A, B,C, As, S, Co) , CA,B,C,As] , [S,Co] ) .  1 

direction(halfadd(A,B,S,C) ,  [A,B]  ,  [S.C] ) .  j 

direction(or_gate(A,B,Out) , [A.B] , [Out] ) .  ^ 

direction(xor_gate(A,B,Out) , [A,B] , [Out] ) . 
direction(aiid_gate(A,B,Out)  ,  [A.B]  ,  [Out]  ) . 
direction(nnot_gate(A,B) ,  [A] , [B] ) . 
direction(nand_gate(A,B,C) , [A.B] , [C] ) . 

primitive(or_gate) . 
primitive(xor_gate) . 
primitive(and_gate) . 
primitive(nnot_gate) . 
priinitive(ncuid_gate) . 

/*Test  Results.’'/ 

Script  VI. 0  session  started  Hon  Oct  14  15:04:07  1991 

Microsoft(R)  MS-D0S(R'  Version  4.01 

(C)Copyright  Microsoft  Corp  1981-1988 

A : \THESIS\CODE>prolog 


+ - + 

I  MS-DOS  Prolog-1  Version  2.2  I 
I  Copyright  1983  Serial  number:  0001213  I 
I  Expert  Systems  Ltd.  i 
I  Oxford  U.K.  i 


/*  Loading  the  specialization  code-fiie.  */ 


?-  [speccode] . 
speccode  consulted 
?-  test4. 

I*  This  is  the  modified  circuit  definition  gener<ited  by  the  process.  .N'otice  that  the  circuit 
is  structured  hierarchically.  The  built-in  procedure  "listing”  is  used  to  expose  each  level 
of  the  hierarchy.  */ 

asserting  foo4(al,bl ,c,as,a2,b2,s2,sl) :-Cfoo3(a2,b2,T2,s2) , 
addsub'Cal  ,bl  ,c,as,sl  ,T2)] 
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retracting  Ca2 , b2', T2 , as , a  1 , b  1 , c , as] 

asserting  direction(foo4(al ,bl ,c ,as ,a2,b2,s2,sl) , 
[al ,bl,c,as,a2,b2] , Cs2,sl])) 

Circuit  =foo4(al ,bl ,c,as ,a2,b2,s2,sl) 
yes 

?-  listing(foo3) . 
foo3(a2,b2, ’T2' ,s2) 

[foo2(b2, ’T2' ,'T6’) ,fool(a2.’T6’,s2)]  . 


yes 

?-  listing(foo2) . 
foo2(b2,’T2',’T6>) 

[xor_gate(b2,’T2’,’T6')]  . 


yes 

?-  listing(fool) . 
fool(a2,’T6’,s2) 

Cxor_gateCa2, ’T6’ ,s2)]  . 


yes 

?-  ha:-.. 

A:\THESIS\CODE>exit 

Script  completed  Hon  Oct  J4  15:05:44  1991 
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VII.  Results  and  Recommendations 


7. 1  Extraction 

7.1.1  Results.  The  basic  principles  of  circuit  extraction  were  explained  in  Chap¬ 
ter  4.  The  extraction  process  is  a  fairly  simple  process  if  the  following  assumptions  are 
made. 

1.  Extractions  will  only  be  done  within  the  current  level  of  the  hierarchy.  If  some  of  the 
constituent  components  to  be  extracted  lie  at  one  level  of  the  hierarchy  and  the  rest 
lie  at  another  level,  to  remove  the  group  and  reassert  some  higher-level-level  structure 
could  completely  change  the  overall  function  of  the  circuit.  Prolog  programs  that 
ensure  that  the  extraction  process  will  not  violate  connectivity  are  being  developed 
(26:4-8.1). 

2.  E.xtractions  can  be  done  without  consideration  for  critical-path  delays.  If  timing  is  a 
crucial  factor  in  the  design  of  a  circuit,  extracting  groups  of  components  with  some 
set  propagation  delay  time  and  inserting  a  substitute  component  with  a  different 
delay  time  could  seriously  affect  the  circuit’s  operation.  Extraction  programs  that 
account  for  changes  in  critical  path  delay  are  being  developed  at  AFIT  (25). 

7.1.^  Recommendations.  The  extraction  process  can  be  used  in  many  areas  of  dig¬ 
ital  circuit  design  as  long  as  the  process  is  closely  monitored  by  skilled  engineers.  More 
work  could  be  done  to  shift  the  burden  of  verifying  the  correctness  of  the  extraction  pro¬ 
cess  from  the  engineer.  This  will  involve  developing  sophisticated  extraction  prograiiia  that 
exploit  advanced  logic  programming  techniques.  Work  is  proceeding  at  .AFIT  on  advanced 
applications  of  logic-programming  to  circuit  extraction  (25) 

7.2  Simulation 

7.2.1  Result.'!.  The  simulation  of  digital  circuit  operation  can  be  quick  and  efncienl 
when  Prolog  is  used.  TTLS  provides  a  convenient  method  for  the  testing  of  digital  circuits 
on  the  TTL  level  and  could  easily  be  modified  to  simulate  circuits  designed  with  lower-level 
components.  .Several  digit.al  circuit  simulators  are  used  at  AFIT,  but  they  all  operate  much 
slower  than  TTLS.  TTLS  achieves  its  high  simulation  speed  through  the  use  of  •‘structured- 
invocation”  and  “stack  instantiation”  (explained  in  detail  in  Chapter -5).  TTLS's  utilization 
of  structured  invocation  and  stack  instantiation  distinguish  TTLS  from  other  simulators 


developed  in  the  past.  An  e.xtensive  review  of  the  literature  did  not  uncover  another 
simulator  that  employed  these  qualities. 

1.2.2  Recommendations.  TTLS  can  be  developed  into  a  large-scale  digital  circuit 
simulator  capable  of  providing  very  fast  simulation  results  over  a  broad  range  of  TTL 
device  types.  The  development  of  a  large  scale  Prolog-based  simulator  could  be  used  by 
the  VLSI  laboratory  as  a  simulation  tool  and  by  the  electronics  laboratory  as  a  teaching 
aid.  The  concept  of  “machine  intelligence"’  could  also  be  embodied  in  a  TTL  simulator  b\ 
incorporating  some  of  the  principles  associated  with  extraction  into  the  simulator’s  design. 
For  example.  The  simulator  could  scan  the  wire-list  for  groups  of  gates  that  perform 
a  specified  function  (similar  to  ‘.he  XOR-gate  function  performed  by  four  N.-VND-gates 
discussed  in  Chapter  4)  and  sugg  "t  that  the  four  N.A.ND-gates  be  replaced  with  one  XOR- 
gate.  This  would  be  a  very  atti  tctive  option  if  XOR-gates  were  used  elsewhere  in  the  test 
circuit. 

TTLS  also  has  the  potential  to  be  developed  into  an  effective  fault  diagnosis  tool. 
Given  that  a  device  or  a  number  of  devices  in  a  circuit  were  faulty,  TTLS  could  be  used 
to  simulate  the  defective  circuit's  operation  and  detect  devices  or  combinations  of  devices 
capable  of  causing  the  malfunction.  Specific  heuristics  could  be  developed  to  guide  TTLS  in 
its  search  for  defective  components.  Because  of  the  completeness  of  Prolog's  built-in  search 
strategy,  all  possible  combinations  of  defective  devices  capable  of  causing  the  malfunction 
would  be  found. 

7.3  Specialization 

7.3.1  Results.  The  specialization  of  a  general  class  of  electronic  circuits  was  show  n 
to  be  practical.  Critical  path  timing  constraints  and  hierarchical  boundaries  are  not  a 
problem  in  the  specialization  process  as  onl>  those  components  that  do  not  directly  con¬ 
tribute  to  the  circuit's  operation  are  removed.  The  code  developed  for  this  thesis  ha-, 
been  tested  over  a  range  of  circuit  design.'^.  Each  test  removed  all  redundant  componert:' 
and  correctly  derived  the  new  circuit  specification.  The  original  algorithm  proposed  bv 
Clocksin  was  expanded  upon  by  including  another  predicate,  direction,  in  the  scheme. 
When  a  specialized  submodule  was  inspected  by  the  user,  it  was  not  easy  to  distingui.-li 
input  ports  from  output  ports.  However,  by  storing  the  input/output  status  of  a  special¬ 
ized  module’s  ports  in  the  form  of  the  direction  predicate,  the  status  could  casilv  be 
determined.  Prior  to  the  development  of  the  specialization  code  discussed  in  Chapter  '■>. 


an  extensive  literature  review  uncovered  several  journal  articles  reporting  the  development 
some  of  the  concepts  proposed  by  Clocksin  in  his  original  article  [12].  but  no  mention  of 
any  further  development  of  his  specialization  process  was  found. 

1.3.2  Recommendations.  The  VLSI  program  at  AFIT  does  not  currently  possess  a 
design  tool  capable  of  removing  redundant  circuitry  from  gate-level  designs  and  rewriting 
the  circuit’s  nodal  connections  to  reflect  the  change.  The  concept  of  specialization  and  the 
code  developed  for  this  thesis  should  be  integrated  into  the  VLSI  program. 

Specialization  represents  only  one  member  of  the  cla.ss  of  optimization  procedures 
that  could  be  developed.  The  specialization  code  can  be  enhanced  by  developing  other 
programs  to  perform  circuit  transformations  ba  ’d  on  some  heuristic  other  than  the  mini¬ 
mization  of  a  circuit’s  gate  count.  For  e-xample.  a  program  could  be  developed  that  would 
perform  critical  path  timing  analysis  and  transform  a  circuit  from  a  slow  or  regular-speed 
version  into  a  high-speed  equivalent.  Several  different  programs  could  also  be  developed 
to  handle  the  different  aspects  of  ci^^uit  synthesis  based  on  logic  programming  techniques. 
Circuit  synthesis  systems  such  as  BC  'J  [32],  and  Socrates  [22,  29,  21,  30)  were  developed 
several  years  ago  and  do  perform  circuit  synthesis,  but  the  bulk  of  the  process  is  performed 
by  an  expert  system  usually  written  in  a  language  other  than  Prolog.  Developing  a  logic 
circuit  synthesis  system  based  solely  on  logic  programming  would  be  a  large  task,  but  one 
worthy  to  undertake. 


Appendix  A.  Extraction  Code  and  Test  Results 
A. I  Extraction  Code 

A.l.l  Prolog  Code  for  the  Extraction  Process 


!*  extract. pro  */ 
/*  This  procedure  will  extract  all  possible  Full  Adder  */ 
f*  circuits  from  any  input  netlist.  The  procedure  will  */ 
/*  extract  all  NAND-gate  configurations  of  XOR-gates  */ 
/*  first.  Once  all  XOR-gates  have  been  found,  full  adder  */ 
/*  combinations  are  sought.  For  simplicity,  only  HAND  */ 
/*  and  XOR-gates  are  used.  The  built-in  procedure  */ 
I*  "listing(X)"  is  used  to  print  database  entries  for  */ 
/*  the  variable  "X"  to  the  screen.  */ 
/*  */ 
/*  A  typical  session  would  be:  */ 
/*  ?-  consultC ’extract. pro’ ) -  */ 
/*  yes  */ 
/*  ?-  consultC ’netlist. pro’ ) .  */ 
/*  yes  *! 
/*  ?-  extract_full_adders .  */ 
/*  yes  */ 
/*  listing(full_adder) .  */ 
/*  full_adder(x,y,z,s,c) .  */ 
/*  yes  */ 


/♦;(t******^[*******%**code  starts  here*“****''********“''*****^**/ 

extract_full_adders  :- 
find_xor_gates, 
f ind_f ull_adders . 

/*  The  input  nodes  could  be  transposed.  To  compensate,  */ 


/*  the  code  is  written  so  that  inputs  X  and  Y  are  the  same  */ 
/=•'  as  inputs  Y  and  X.  The  built-in  procedure  "fail"  is  */ 
/♦  used  to  force  the  interpreter  to  find. all  possible  */ 
/*  solutions,  "retract"  and  "assert"  are  not  undone  *! 
/*  during  the  backtracking  caused  by  the  "fail"  procedure.  */ 


f ind_xor_gates 

(nand_gate(X,Y,Tl) ; 
nand_gate(Y,X,Tl)) , 
(nand_gate(Tl ,Y,T3) ; 
nand_gate(Y,Tl,T3)) , 
(nand_gate(X,Tl ,T2) ; 
nand_gate(Tl ,X,T2)) , 
(nand_gate(T2,T3,0ut) ; 
nand_gate(T3,T2,0ut)) , 
(retract(nand_gate(X,Y,Tl)) ; 
retract (nand.gate(Y,X,Tl))) , 
(retract(nand_gate(Tl,Y,T3)) ; 
retract (nand_gate(Y,Tl ,T3))) , 
(retractCnand.gateCXjTl.l^)) ; 
retract (nand_gate(Tl,X,T2))) , 
(retract(nand_gate(T2,T3,0ut)) ; 
retract(nand_gate(T3,T2,0ut))) , 
assertCxor.gateCX.YjOut)) , 
fail. 

f ind_xor_gates. 


/*  The  search  is  the  same  as  for  the  XOR-gates,  only  the  */ 

/*  pattern  (what  we  are  looking  for)  changes.  */ 


.■\ -2 


find.full.adders 


(xor_gate(X,Y,Tl) ; 
xor_gate(Y,X,Tl)) , 
(xor_gat'^CZ,Tl,S) ; 
xor_gate(Tl,Z,S)) , 
(nand_gate(X,Y,T2) ; 
nand_gate(Y,X,T2)) , 
(nand_gate(Z,Tl,T3) 
nand_gate(Tl,Z,T3))., 
(nand_gate(T2,T3,C) 
nand_gate(T3,T2,C))., 
Cretract(xor_gate(X,Y,Tl)) ; 
retract(xor_gate(Y,X,Tl))), 
(retract(xor_gate(Z,Tl,S)) ; 
retract(xor_gate(Ti ,Z,S))) , 
(retract(nand_gate(X,Y,T2)) : 
retract(r.and_gate(Y,X,T2))) , 
(reT;ract<nand_gate(Z,Tl,T3)); 
retract  (nand.gate(Tl,ZJ3))) , 
(retract(nand.gate(T2,T3,C)) ; 
retract(naiid_gate(T3,T2,C))) , 
assert(fuil_adder(X,Y,Z,S,C)) , 
fail. 


ind_full_adders . 


A. 2  Netlist  Code 


A. 2.1  Prolog  Code  for  the  Netlist 

/****!(t**********!(<***3t!**!|!***#**!t;*****  +  **3|Cl(t*!«*  ♦♦♦*****♦*  **♦**♦/ 

/*  netlist. pro  */ 

/*  This  code  descibes  the  test  circuit  used  with  the  */ 

/*  procedure  "extract. pro"  for  the  full  adder  extraction  */ 
/*  example.  Exactly  one  full-adder  is  modeled.  */ 

/*  First  XOR-gate  */ 

nand_gate(x,y ,tl) .  /*  note  that  internal  connections  are  */ 

naiid_gate(y ,tl ,t3) .  /*  modelled  with  the  letter  "t"  */ 

nand_gate(x,tl ,t2) .  /*  followed  by  some  number.  */ 

nand_gate(t2,t3,t4) . 

/*  second  XOR-gate  */ 

nand_gate(t4,z,tl) . 
nand_gate(t4,tl ,t2) . 
nand_gate(z,tl,t3) . 
nand_gate(t2,t3,s) . 


/*  remainder  of  the  gates  in  the  full  adder  ♦/ 


nand_gate(x,y ,t6) . 
nand_gate(z,t4,t5) . 
nand_gate(t6,t5,c) . 


A. 3  Extraction  Test  Results 


/+  TEST  RESULTS  */ 

I*  The  program  "extract .pro"  and  "netlist.pro"  are  needed  */ 
/*  to  produce  the  test  results  given  below,  "extract .pro"  */ 
/*  provides  the  code  to  perform  the  extract  function.  */ 

/*  "netlist.pro"  is  a  netlist  of  NAND-gates  which  describe  */ 
'  /*  a  full-adder,  "extract .pro"  will  search  through  any  */ 
/*  netlist  given  to  it,  and  extract  all  the  NAND-gate  */ 

/*  full-adder  circuits  which  it  can  find.  In  this  example,  */ 
/*  "extract .pro"  extracts  all  the  full-adders  from  */ 

/*  "netlist.pro".  When  a  full-adder  is  found,  the  */ 

/*  constituent  NAND-gates  are  retracted  from  the  database  */ 
/*  and  a  full-adder  is  asserted  in  their  place.  */ 


/#*  +  **:(c*****i(ii((  ***♦!(<*********♦**:♦;*♦*♦  Jtt***********************/ 

Script  VI. 0  session  started  Mon  Sep  02  12:44:22  1991 

Microsoft(R)  MS-DOS(R)  Version  4.01 

(C)Copyright  Microsoft  Corp  1981-1988 

J : \THESIS\CODE>prolog 


+ - 4 

I  MS-DOS  Prolog- 1  Version  2.2  I 

I  Copyright  1983  Serial  number:  0001213  I 

I  Expert  Systems  Ltd.  I 

1  Oxford  U.K.  I 

+ - + 


?-  [extract].  /*  This  command  loads  "extract .pro" .  */ 

extract  consulted. 


*/ 


I*  The  built-in  predicate  "listing(X)"  will  find  all 


/*  expressions  for  X  and  print  them  on  the  screen.  */ 

?-  listing(nand_gate) .  /*  Checking  the  netlist  to  ensure  */ 

/*  that  it  was  loaded  correctly.  */ 

nand_gate(x,y ,tl)  . 
nand_gate(y,tl,t3)  . 
nand_gate(x,tl,t2)  . 
nand_gate(t2,t3,t4)  . 
nand_gate(t4,z,tl)  . 
nand_gate(t4,tl ,t2)  . 
nand_gate(z,tl,t3)  . 
nand_gate(t2,t3,s)  . 
nand_gate(x,y ,t6)  . 
nand_gate(z,t4,t5)  . 
nand_gate(t6,t5,c)  . 

/*  Some  before-extraction  tests,  run  on  the  database*/ 

/*  to  ensure  there  are  no  unwanted  gates  present.  */ 

yes 

?-  listing(xor_gate) .  /*  no  XOR-gates  listed  */ 

yes 

?-  listing(full_adder) .  /+  no  full-adders  listed  */ 
yes 

?-  extract _full_adders .  /*  invoking  the  algorithm  */ 

yes 

?-  listing(nand_gate) .  /*  all  NAND-gates  are  gone  */ 

yes 

?-  listing(xor_gate) .  /♦  all  XOR-gates  are  gone  */ 

yes 
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?-  listing(full_adder) .  /*  one  full  adder  was  found  */ 


full_adder(x,y ,2,s,c)  . 


yes 

?-  halt.  /*  finished  */ 


J:\THESIS\CODE>exit 

Script  completed  Hon  Sep  02  12:46:22  1991 


Appendix  B.  Digital  Circuit  Simulation  Code  and  lUsults 


B.l  Four- Bit  Binary  Adder  Code  and  Simulation  Results 
B.l.J  Prolog  Code  for  a  Four-Bit  Binary  Adder 

/if**if^i^:*:t::t::^ifyt:yif3t:**^:iif:t:tif^t:t‘********************************:ti*****/ 

/*  addrcode.pro  */ 

/*  This  program  exploits  hierarchical  structures  in  Prolog  */ 
/*  by  exploring  digital  circuit  relationships.  A  NAND-gate  */ 
/*  is  defined  as  the  only  primitive  element.  Groups  of  */ 
/*  NAND-gates  are  hierarchically  formed  into  XOR-gates.  */ 
/*  The  XOR-gates  coupled  with  more  NAND-gates  will  form  */ 
/*  full-adders.  Four  full-adders  will  be  linked  to  form  */ 
/*  one  four-bit  adder.  */ 

/*  The  following  procedure  defines  the  primitive  element,  */ 
/*  the  NAND-gate.  Only  two-input  NAND-gates  will  be  used.  */ 
/*  Input  signals  will  be  denoted  by  the  variables  X  and  Y.  */ 
/*  The  output  will  be  denoted  by  the  variable  Z.  The  clause*/ 
/*  is  written  in  the  form  naiid(X,Y,Z) .  */ 

/**  +  *******  +  :t'********  +  ************3t:=tt******************  +  ******/ 

/♦*****;ti*********CQd9  starts  here****************************/ 

nand(0,0, 1) . 
nand(0, 1 ,1) . 
nandd ,0, 1) . 
nand( 1,1,0) . 

/*  The  following  rule  hierarchically  defines  the  XOR-gate  */ 
/*  function  in  terms  of  NAND-gates.  Again  only  two-input  */ 
/*  XOR-gates  will  be  considered.  Input  signals  */ 

/*  will  be  denoted  by  X  and  Y,  output  with  Z.  */ 

xor(X,Y,Z)  :- 
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nand(X,Y,Tl), 

nand(X,Tl,T2), 

nand(Y,Tl,T3), 

nand(T2,T3,Z). 


/*  Groupings  of  NAND  and  XOR-gates  are  used  in  the  */ 
/*  following  rule  to  define  a  full-adder.  The  device  will  */ 
/*  be  modeled  with  three  input -terminals,  X,  Y,  and  Z.  */ 
/*  Outputs  will  be  a  sum  denoted  with  an  S  and  a  carry  */ 
/*  denoted  with  a  C.  *! 


full_adder(X,Y,2,C,S)  :- 
nand(X,Y,T2) , 
xor(X,Y,Tl), 
nand(Z,Tl ,T3) , 
xor(Z,Tl ,S) , 
nand(T2,T3,C). 

/+  The  following  rule  defines  a  four-bit  *! 

/*  binary-adder  in  terms  of  four  full-adders.  */ 

bin_adder(bin(X3,X2,Xl,X0),bin(Y3,Y2,Yl,Y0),bin(C3,S3,S2,Sl,S0)) 
f  ul  1  _  adder  ( XO ,  YO ,  0 ,  CO ,  SO )  , 
full_adder(Xl , Y1 ,C0,C1 ,S1) , 
f ull _  adder ( X2 , Y2 , C 1 , C2 , S2) , 
full_adder(X3,Y3,C2,C3,S3). 

/***♦**♦****:»*+♦****♦♦  **++;tt*xhe  End*************’''***********/ 
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B.1.2  Four-Bit  Binary-Adder  Simulation  Results 

/  +  *:jc**!(t*4:**********  +  *************  +  *:tc***  +  ***;(i!(::(c*»;*******#:(c***  +  3(t/ 


/**  addrrun.pro  **/ 
/♦♦Script  session  of  addrcode.pro.  This  session  contains  ♦♦/ 
/♦♦several  sample  simulations  of  the  operation  of  a  ♦♦/ 
/♦♦four-bit  binary-adder.  *♦/ 


/  ****:(c!(t***j(c********!(c**!f;***************^c***********:t;^c**3(t*:(!*^t***/ 

Script  VI. 0  session  started  Mon  Sep  09  09:24:35  1991 

Microsoft(R)  MS-DOS(R)  Version  4.01 

(C)Copyright  Microsoft  Corp  1981-1988 

J : \>prolog 

+ - + 

I  MS-DOS  Prolog-1  Version  2.2  I 

I -Copyright  1983  Serial  number:  0001213  | 

I  Expert  Systems  Ltd.  I 

I  Oxford  U.K.  I 

+ - + 

?-  [addrcode] .  /♦♦  load  addrcode  ♦♦/addrcode  consulted. 

/♦♦Test  with  all  inputs  set  equal  to  zero**/ 

?-  bin_adder(bin(0,0,0,0),bin(0, 0,0,0) ,bin(C3,S3,S2,Sl ,S0)) . 

C3  =  0 
S3  =  0 
S2  =•■  0 
SI  =  0 
SO  =  0 

More  (y/n)?  y 
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no 


/**Test  binary  1  added  to  binary  15  **/ 

?-  bin.adder (bind,  1,1,1)  ,bin(0, 0,0,1)  ,bin(C3,S3,S2,Sl,S0)) . 

C3  =  1  /**  Carry  bit  is  high,  all  others  are  low.**/ 

S3  =  0 
S2  =  0 
SI  =  0 
SO  =  0 

More  (y/n)?  y 

no 

/**Reverse  simulation  test.  Given  that  all  X  inputs  are  set**/ 

/**to  zero  and  the  output  is  given  as  binary  1,  what  must  **/ 
/**value  at  Y  have  been  ?**/ 

?-  bin.adder (bin(0, 0,0,0) ,Y,bin(0,0,0,0,l)) . 

Y  =  bin(0, 0,0,1)  /**Correct  value**/ 

More  (y/n)?  y 

no 

/♦♦Another  reverse  simulation.  If  the  output  was  zero,  what**/ 
/♦♦possible  input  combinations  are  there  ?**/ 

?-  bin_adder(X,Y,bin(0,0,0,0,0)) . 

X  =  bin(0, 0,0,0)  /**  This  is  the  only  possible  input  combination**/ 

Y  =  bin(0, 0,0,0) 

More  (y/n)?  y 

no 
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/**With  the  output  set  at  1,  Find  all  possible  input  **/ 
/♦♦combinations . *♦/ 

?-  bin_adder(X,Y,bin(0,0,0,0,l)) . 

X  =  bin(0, 0,0,0)  /♦♦One  of  two^*/ 

I 

Y  =  bin(0, 0,0,1) 

More  (y/n)?  y 

X  =  bin(0, 0,0,1)  /♦♦two  of  two^*/ 

Y  =  bin(0, 0,0,0) 

More  (y/n)?  y 

no 

/♦♦Find  all  possible  input  combinations  for  an  output^^/ 
/♦♦equal  to  binary  2.**/ 

I 

?-  bin_adder(X,Y,bin(0,0,0,l,0)) . 

X  =  bin(0, 0,0,0)  /♦♦There  are  three  possibilities^^/ 

Y  =  bin(0, 0,1,0) 

More  (y/n)?  y 

X  =  bin(0, 0,1,0) 

Y  =  bin(0, 0,0,0) 

More  (y/n)?  y 

X  =  bin(0, 0,0,1) 

Y  =  bin(0, 0,0,1) 

More  (y/n)?  y 

no 

?-  halt. 

J:\>exit 

Script  completed  Hon  Sep  09  09:31:51  1991 


B.2  JK  Flip-Flop  Code  and  Sinndalion  Results 
B.2.I  Prolog  Code  for  a  JK  Flip-Flop 


/****:(t**  *****♦*+*********  ♦♦*******:(c:(e***+^:(C**:|c  **********;*: 

/**  jkcode.pro  **/ 

/**  This  code  simulates  the  operation  of  a  jk  flip-flop.  **/ 

/**  Input  sequences  are  assumed  to  be  the  same  length.  **/ 

/**  A  list  of  all  state  transitions  is  returned,  **/ 

/**  The  predicate  is  formed  as:  **/ 

/**  **/ 
/**  jksim( [JlJr] , [KlKr] ,Ps,  [NsiNr]) .  **/ 

/**  **/ 
/**  Where:  JlJr  is  the  list  of  inputs  to  the  J-port.  **/ 

/**  KlKr  is  the  list  of  inputs  to  the  K-port.  **/ 

/**  Ps  is  the  present  state  -  Note  that  the  ■  **/ 

/**  present  state  must  be  specified  inorder  to  **/ 

/**  initiate  the  session.  **/ 

/**  Ns  I  Nr  is  the  list  of  state  transitions  which  **/ 

/**  correspond  to  the  sequence  of  input  values  **/ 

/*♦  **/ 
/**  A  typical  session  would  be:  **/ 

/**  **/ 
/**  ?-jksim(Cl,0,l,i,lj ,C0,i,l.l,0j ,0,Q).  **/ 

/**  Q  =  Cl, 0,1. 0,1]  **/ 

!**  more  (y/n)  y  **/ 

/**  no  **f 

/**  **/ 
/;(c***^t*********^**:(t***  ********♦****#**♦**********¥**♦*♦*****/ 

/♦:4c:(c***+***#**itc*T{ie  code  starts  here************************/ 

jksimCC]  ,[],_,[]) .  /*boundry  condition  */ 

jksim(CJ| Jr] , [KlKr] ,Ps, [NsINr])  :- 
jkff(J,K,Ps,Ns), 
jksimCJr ,Kr,Ns ,Nr) . 
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/**  The  operation  of  the  JK  flip-flop  is  defined  in  boolean**/ 
/♦*  terms  with  the  following  facts.  **/ 

jkff(0.0,0,0). 
jkff(0, 0,1,1). 
jkff (0,1,0,0) . 
jkff (0,1,1,0) . 
jkffd, 0,0,1). 
jkffCl, 0,1,1). 
jkff (1,1, 0,1) . 
jkff (1,1, 1,0) . 

again  : - 

reconsult (jkcode) . 


I 


s 

I 

I 


B.2.2  JK  Flip-Flop  Simulation  Results 

/**  jkrun.pro  */ 

/**  This  is  the  script  session  of  jkcode.pro.  This  session  */ 
/**  contains  several  sample  simulations  of  the  operation  of  */ 
/**  a  JK  flip-flop.  *! 

Script  VI. 0  session  started  Tue  Sep  10  11:40:29  1991 

Microsoft(R)  MS-DOS(R)  Version  4.01 

(C)Copyright  Microsoft  Corp  1981-1988 

A : \THESIS\CODE>prolog 

+ - + 

I  MS-DOS  Prolog- 1  Version  2.2  I 

I  Copyright  1983  Serial  number:  0001213  I 
I  Expert  Systems  Ltd.  I 

I  Oxford  U.K.  I 

+ - + 

?-  [jkcode] .  !**  load  jkcode.pro  **/ 
jkcode  consulted. 

?-  jksimCCO] , [0] ,0,q) .  /*  beginning  an  exhaustive  test  of  ail 

possible  test  cases.  */ 

Q  =  [03 
More  (y/n)?  y 

no 

?-  jksimC [0] , [0] , 1 ,Q) . 

Q  =  [13 

More  Cy/n)?  y 
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no 


?-  jksim([0] , [1] ,0,Q) . 

Q  =  [0] 

More  (y/n)?  y 

no 

?-  jksimCCO] ,  [1] ,1,Q) . 

Q  =  [0] 

More  (y/n)?  y 

no 

?-  jksimCCl] , [0] ,0,Q) . 

Q  =  Cl] 

More  (y/n)?  y 

no 

?-  jksim(Cl],C0],l,Q). 

Q  =  Cl] 

More  (y/n)?  y 

no 

?-  jksim(Cl] , Cl] ,0,Q) . 

Q  =  Cl] 

More  (y/n)?  y 

no 

?-  jksim(Cl],Cl],l,Q). 

Q  =  CO] 

More  (y/n)?  y 

no 

?-  jksiin(Cl,0,l,l,l]  ,  CO, 1,1,1 


/*  all  cases  test  fine.  */ 


,0],0,Q).  /*testing  an  input  */ 
/*  sequence  */ 


Q  =  Cl, 0,1, 0,1] 
more  (y/n)?  y 
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no 


?-  halt. 

A:\THESIS\CODE>exit 

Script  completed  Tue  Sep  10  11:45:50  1991 
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B.3  TTLS  Pattern- Detection  Example  Derivation 

B.3.1  Derivation  of  the  Pattern- Detection  Sequential  Netiuork.  The  derivation  of 
the  Mealy  network  given  in  Chapter  5  is  discussed  here  for  convenience.  The  operation  of 
the  pattern-detector  is  completely  described  by  Figure  B.l. 

The  State-table  can  be  derived  directly  form  the  Mealy  graph  by  filling  the  table  in 
for  the  appropriate  transitions  (43j.  The  corresponding  State-table  is 


Table  B.l.  State-table  for  Figure  B.l. 


State 

State  Assignment 
AB 

Next  State 

X  =  0 

Next  State 

X  =  1 

Output 

X  =  0 

Output 

X  =  1 

SO 

00 

01 

00 

0 

SI 

01 

11 

00 

0 

S2 

11 

11 

10 

0 

1 

S3 

10 

01 

11 

0 

0 

The  next  state  and  output  maps  can  be  constructed  directly  from  table  B.l.  The 
general  Karnaugh  maps  of  Figure  B.2  must  no%v  be  modified  in  accordance  with  the  char¬ 
acteristic  equation  of  the  type  of  flip-flop  used.  The  3li  flip-flop  used  in  the  example.  JA' 
flip-flops  are  positive  edge  triggered  flip-flops  and  are  listed  in  the  TTL  data-book  as  type 
SN74109.  See  Table  B.2  for  the  complete  definition  of  allowable  .Ji?  state  transitions.  The 
JA'  flip-flop  specific  Karnaugh  maps  and  the  output  map  along  with  the  collected  terms 
and  appropriate  equations  are  given  in  Figure  B.3. 


Table  B.2.  State  transition  table  for  a  JA'  flip-flop. 


J 

K 

Ps 

Ns 

0 

0 

0 

1 

0 

0 

0 

1 

0 

1 

0 

0 

0 

1 

1 

1 

1 

0 

0 

1 

1 

0 

1 

0 

1 

1 

1 

0 

1 

1 

1 

0 

The  logic  equations  derived  from  the  maps  of  Figure  B.3  can  now  be  used  to  derive 
the  schematic  diagram  of  the  network  and  the  Prolog  code  which  simulates  the  network's 
operation.  Figure  5.10  gives  the  gate-level  representation  of  the  circuit. 
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B.4  TTLS  Code 


B.Jfl  TTLS  Code  and  Demonstration  Circuit-Files 

/**^<********:(t***:t!!*:********ttl  .pTO************************* / 

/**  This  file  sets  up  the  simulation.  **/ 

?-  write (’Loading  TTLSIM.PRO. ’) ,nl, 
reconsult (ttlsim) , 
write ( ’Loading  TTLDATA.PRO. ’) ,nl, 
reconsult (ttldata) , 
write (’Loading  SETUP . PRO ’), nl , 
reconsult (setup) , 
nl, 

write  (’Type  ”go”  at  the  next  prdmpt  to  start  the  process. ’)  ,nl, 
write(’Be  sure  to  end  all  commands  with  a  period. ’) ,nl,nl. 

/♦***********!t!****#*****+*#*****The  End**********************/ 


/>(c**;*:ic:(c************!(c*:jt:)t*se'CUp  .  pi  0=*=**^********* +  ***  ************/ 
/**  This  file  sets  up  the  simulation  by  supplying  the  user  **/ 
/**  with  some  basic  information  concerning  input  files  and  **/ 
/**  asking  the  user  which  file  he/she  desires  to  load.  **/ 


go 

writeC’Two  demonstration  files  are  provided  with’),nl, 

writeC’this  simulator.  The  first’), 

write(’ , ’) ,write(’  CKTl.PRO’) ,write(’ , , 

writeC’  describes  a  full-adder .’) ,nl, 

write (’The  second’), 

write(’ , ’) ,write(’  CKT2.PR0’) ,write(’ , ’) , 
write (’describes  a  pattern-detector  which’), ni, 
write ( ’generates  an  output  (1)  each  time  the  input’), 
write(’  stream  has  at  least ’),nl, 

write(’two  zeros  followed  by  an  odd  number  of  ones.’),nl, 
write(’If  you  want  to  simulate  your  own  circuit  file;’),nl, 
write(’type  the  file  name  at  the  prompt.  Your  file’),nl, 
write ('must  have  the  form  ' ’filename. pro’ ’  but  type  only’),nl, 
write(’the  file  name  at  the  prompt.  You  may  return  to  dos’),nl, 
write(’at  any  time  by  typing  ’’halt.’’  at  the  prolog’), 
write (’  prompt. ') ,nl, 
nl, 

write(’V/hich  file  wou''d  you  like  to  simulate?’), 
write(’  >  ’),  write(’ (ckti , /ckf? . '’'lOurfile)  ’ )  ,nl, 
read(File) , 
procede(File) . 

procede(cktl)  :- 

write ( ’Loading  CKTl .PRO’) ,nl, 
reconsult (cktl) , 

run.  /**  run  starts  ttlsim.pro**/ 
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precede (ckt2)  ■ 

write (’Loading  CKT2.PR0’) ,nl, 

reconsult(ckt2) , 

run. 

precede (File) 

write  (’Loading  ’)  .write ''^■ie) ,  write  (’  .PRO’)  ,nl , 

reconsult (File) , 

run. 

/♦****:(c**;t(:it  +  *****:(cv******Xhe  End******V***:f*1c****:tt******:tc*3)t*:(c*/ 


/ ***********»**+****+****ttloiin.pro***************************/ 
/**  Th-=  user  must  number  his  package  types  with  unique  ic  **/ 
/•'“*  numbers  if  the  total  number  of  individual  gates  exceeds  **/ 
/**  the  number  of  gates  available  on  the  ic  package.  For  **/ 
/**  example  if  six  NOR-gates  were  going  to  be  used  the  first**/ 
/**  four  gates  would  come  from  id  (.tiiice  an  SN7402  has  4  **/ 
/**  gates  per  package)  and  the  remaining  two  gates  fn'm  **/ 
/**=  gates  from  ic2.  **/ 

/  ^^il■|f1H^Af■¥^^■^■**^^***iet■**^****^^**^^*****^H^■***■*■**1^•^i^**■•  / 

/**  run  starts  the  simulation  process  by  invoking  the  **/ 
/**  procedure  build_circuit(QArgs) .  QArgs  are  the  arguments**/ 
/**  necessary  for  the  simulation  ox  memory  devices.  QArgs  **/ 
/**  has  the  form  [[[Q.NotQ]  ,  L'Q+,NotQ+3]  , . . .]  with  two  lists**/ 
/**  of  two  entries  for  each  memory  device.  The  first  list  **/ 
/**  represents  the  present  state  and  the  present  state’s  **/ 
/**  negation.  The  second  list  represents  the  future  state  **/ 
/**  and  the  futur'*  state’s  negation.  **/ 
/**  set_up.state^QArgs, States)  takes  the  list  of  memory  **/ 
/**  device  arguments  (QArgs)  and  inserts  the  boolean  vaine?'*/ 
/**  [0,1]  into  the  list  which  represents  each  memory  **/ 
/**  device’s  future  state  arguments.  These  will  later  be  **/ 
/**  shifted  into  the  list  representing  the  present  state  **/ 
/**  arguments  immediately  prior  to  the  first  cycle  of  the  **/ 


/**  simulation.  This  will  effectively  clear  all  memory  **/ 
/**  devices.  In  order  for  any  simulation  to  provide  **/ 
/**  consistent  results,  the  memory  devices  must  be  **/ 
/**  initialized  to  a  known  state.  **/ 
/**  The  final  step  in  the  process  is  performed  by  **/ 


/**  ovaluate_circuit(Lists, States, OutputList) .  Lists  is  the**/ 
/**  list  of  input  test  values  provided  by  the  user.  States  **/ 
/**  is  discussed  above.  OutputList  is  the  list  of  output  **/ 
/**  values  which  result  from  the  simulation.  **/ 
/**  The  last  few  lines  of  code  allow  additional  input  **/ 
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/**  values  to  be  entered  directly  from  the  keyboard.  **/ 


run 

build_circuit(qArgs) . 
input_sequence(Lists) , 
set _up_state(QArgs, States) , 

writeC-’CLOCK  CYCLE’ )  »tab(5)  ,  /**fonnatting  the  output**/ 
write(’ INPUT  VALUES’ ) .tab (10) , 
write (’OUTPUT  VALUES ’),nl, 
evaluate_circuit(Lists,States .O.OutputList) , 
nl, 

write(’Do  you  want  to  input  another  simulation’), 
write (’  sequence?  (yes./no.) ’) ,write(’>’) ,nl, 
read(Reply) , 

((Reply  =  yes, 
run_again(QArgs) ) 

t 

writ6(’ simulation  over’)),nl,  halt,  /**  return  to  dos  **/ 

/♦**J(t******#****^t**:(t:(c***:(t***<c*^[:([*}(c  :([*%♦  ..,^:*'5:**-(c#**#*:([:)c:*c****!)c***/ 

/**  rur,_again(QArgs)  allows  the  user  to  run  additional  **/ 
/**  tests  with  new  input  sequences.  The  new  sequences  are  **/ 
/**  input  directly  from  the  keyboard.  Since  the  circuit  **/ 

/**  whose  operation  is  to  be  simulated  has  already  been  **/ 
/**  derived,  there  is  very  little  computational  overhead  **/ 
/**  involved  in  these  subsequent  simulations;  therefore  the**/ 
/**  output  results  are  reported  almost  immediately  to  the  **/ 
/**  user.  The  structured  feature  of  rhe  circuit's  predicate**/ 


/**  is  also  used  here.  If  the  user  fails  to  input  a  list  **/ 
/**  with  the  proper  format,  the  procedure  will  fail  and  *»/ 
/**  prompt  for  another  input.  The  failure  results  from  the  **/ 
/**  interpreter’s  inability  to  pattern-match  **/ 
/**  the  newly  formed  predicate  (with  the  incorrectly  **/ 
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/**  formatted  input  list)  with  the  old  previously  defined  **/ 


/**  format.  **/ 
/*■*  If  additional  simulations  are  desired  and  the  new  **/ 
/**  sequence  list  is  formatted  properly,  subsequent  **/ 
/**  simulations  are  performed  by  clearing  any  memory  **/ 
/**  devices  in  the  circuit  and  reconfiguring  another  **/ 
/**  predicate  (Head)  with  the  new  input  values.  **/ 


run_again(QArgs) 

nl, 

write(’ Please  enter  the  new  sequence  as  a  list  of  lists. ’),nl, 
write(’0ne  sublist  should  be  entered  for  each  simulation  ’),nl, 
writeC’clock  cycle  desired.  Each  sublist  should  contain  ’),nl, 
write (’the  correct  number  of  input  values.  Only  the’),nl, 
write (’boolean  values  0  or  1  may  be  entered. ’) ,nl, 
write(’Enter  your  input  now.  Do  not  forget  to’),nl, 

.write(’to  follow  your  entry  with  a  period. ’) ,nl, 
read(NewInput) , 
set_up_state(QArgs, States) , 

write(’CLOCK  CYCLE’) ,tab(5) ,  /**fonnatting  the  output**/ 
write(’ INPUT  VALUES’ ) ,tab( 10) , 
write ( ’ OUTPUT  VALUES ’ ) ,nl , 

evaluate_circuit(NewInput, States ,O,0utputList) , 
nl, 

write(’Do  you  want  to  input  another  simulation’) ,nl, 
write(’  sequence?  (yes./  no.)  ’),  wrice(’>’), 
read (Reply) , 

((Reply  =  yes, 
run_again(QArgs) ) 

(Reply  =  no, 

write (’simulation  over’),nl, 
halt))  /**  return  to  dos  **/ 

f 

(nl, 
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write( ’ERROR:  You  did  not  enter  your  new  input  sequence’) ,nl, 
write(’list  in  the  proper  format.  Enter  the  correct  form  ’),nl, 
write (’of  the  input  sequence. ’) ,nl, 

writeC’Do  you  want  to  try  again?  (yes./no. ) ’ ) ,nl ,  read(NewReply) , 

(NewReply  =  yes, 

run_again(QArgs)) 

i 

(NewReply  =  no, 

write(’ simulation  over’),nl, 

halt)).  /**  return  to  dos  **/ 


/**  set_up_state(QArgs, States)  inserts  the  boolean  values  **/ 
/**  [0,1]  into  each  memory  device’s  next-state  argument  **/ 
/**  list.  At  a  later  stage,  the  values  are  transferred  from  **/ 
/**  the  next-state  list  into  the  present-state  list,  **/ 

/**  effectively  clearing  or  initializing  the  memory  devices**/ 
/**  prior  to  the  initiation  of  the  simulation.  **/ 

set_up_state(  [],[]). 

set_up_state(CCX,Y] IXs] , C[X, [0,1]] |Zs])  :- 
set_up_state(Xs ,Zs) . 

/**  build_circuit(QArgs)  constructs  a  Prolog  executable  **/ 
/**  logic  representation  of  the  circuit  under  test  from  the**/ 
/**  user  provided  wire-list  (wire_list(L)) .  The  wire-list  **/ 
/**  is  first  converted  into  normal  Prolog  list  form.  **/ 

/**  convert_wire_list(wire_list,WireList)  performs  the  **/ 
/**  conversion  by  taking  wire_list  and  removing  some  of  the**/ 
/**  internal  Prolog  "glue".  This  enables  the  modified  list  **/ 
/**  WireList  to  be  treated  as  a  normal  Prolog  list.  Next  «*/ 
/**  get_gates(WireList, WireList, Acc,GateList)  assembles  a  **/ 


/**  list  of  all  gates  occurring  in  WireList  into  the  list  **/ 
/*♦  GateList.  The  accumulator  (Acc)  is  used  to  store  the  **/ 
/**  Prolog-assigned  variable  wire  names.  If  a  wire  name  is  **/ 
/**  encountered  more  than  once  during  the  construction  of  **/ 
/**  the  gate  list,  get_gates  will  ignore  the  repeated  **/ 

/**  entry.  This  avoids  the  repeated  specification  of  **f 

/**  similar  gates.  **/ 

/**  get_inargs(WireList ,Acc,InArgs)  examines  WireList  for  **/ 
/**  for  any  wire  names  which  are  inputs.  The  accumulator  is**/ 
/**  used  for  comparison.  If  a  previously  picked-up  name  **/ 
/**  occurs  again,  the  name  is  not  added  to  the  list  InArgs**/ 
/**  in  order  to  prevent  repeat  entries.  The  list  InArgs  is  **/ 
/**  built  using  a  technique  known  as  bottom-up.  This  allows^*/ 


/**  the  order  of  the  arguments  in  InArgs  to  reflect  the  **/ 
/**  order  of  the  arguments  appearance  in  WireList.  **/ 
/**  get.outargs (WireList, Acc, OutArgs)  works  just  like  **/ 
/**  gat.inargs  except  that  WireList  is  now  scanned  for  any  **/ 
/**  o.’tput  variable  wire  names.  **/ 
/**  get_q_args(GateList,QArgs)  goes  through  the  list  of  **/ 
/**  gates  (GateList)  and  extracts  copies  of  the  arguments  **/ 


/**  of  any  memory  device.  These  are  used  later  to  construct**/ 


/**  the  head  of  the  circuit  and  to  initialize  the  memory  **/ 
/**  devices  prior  to  simulation.  **/ 
/**  the  head  (Head)  of  the  circuit  is  constructed  with  **/ 
/**  "univ".  Each  argument  in  Head  represents  a  structure  **/ 
/**  which  will  be  used  later  in  the  simulation.  By  building**/ 
/**  Head  as  a  composite  of  internal  structures,  this  **/ 
/*♦  procedure  enables  the  user  to  remove  old  values  and  **/ 
/**  insert  new  ones  with  simple,  quick  procedures.  **/ 
/**  unite_circuit(Head, GateList .Circuit)  reapplies  the  **/ 
/**  Prolog  "glue"  which  was  removed  earlier  and  unites  **/ 
/**  Head  with  the  "glued"  GateList  to  form  a  circuit  *»/ 
/**  description  of  the  original  wire_list  which  is  **/ 
/**  expressed  in  executable  Prolog  code.  The  new  circuit  **/ 
/**  (Circuit)  is  asserted  as  a  rule  for  future  use.  Head  **/ 


B.21 


!**■  is  also  asserted.  It  will  be  recalled  later  not  for  **/ 
/**  the  particular  variables  which  it  holds  but  instead  **! 

/♦*  because  it  specifies  the  structure  which  any  future  •*/ 

/**  queries  to  Circuit  must  follow.  *♦/ 

build_circuit(QArgs) 

convert_wire_list(wire_list,WireList) , 
writeC’The  wire  list  is:  ’),nl, 
iist_print(WireList) ,nl , 
get agates (WireList, WireList, n .GateList) , 
get_inargs(WireList,  [] .InArgs) , 
get_outargs(WireList, [] .OutArgs) , 
get_q_args (GateList ,QArgs) , 

Head  =. . [’circuit’ I [InArgs, Out Args.QArgs]] , 
assert (descriptor (Head) ) , 

•  unite_circuit(Head, GateList, Circuit) , 
write(’rne  gate  level  circuit  is:  ’),nl, 
assert (Circuit) , 
list_print(GateList) ,nl. 


convert_wire_list(Head,GoalList)  finds  the  body  which  **/ 
!**  belongs  to  Head  and  removes  the  Prolog  rule  "glue";  *»/ 
/**  hence  allowing  each  goal  of  Body  to  be  treated  as  **/ 
!**  though  it  were  an  element  of  a  list.  **/ 


convert _wire_list(Kead,GoaiList)  :- 
clause(Head,Body) , 
goals_to_iist(Body,GoalList) . 


/«4r*4i*«**«^*4c««4i**«*4i*x*««***  *««**«««*»»******«*«*«  «***»***«/ 

/**  goais_to_list (Structure, List)  removes  the  internal  **/ 
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/**  Prolog  rule  "glue"  and  allows  each  goal  of  Structure 
/**  to  be  treated  as  though  it  were  an  element  of  a  list. 


**/ 


goals_to, list (true, [] )  !. 

goals_to_list( ' , ’ (First (Rest) , [First iConvertRest] ) 

I 

•  > 

goals_to_list (Rest , ConvertRest) . 
goals_to_list(Goal, [Goal]) . 

/**!|t:(l*******!(c**:(e****!)t  +  ;(t**  ***********♦********  +  ***!('***********/ 

!**  get_gates(WireList,WireList,Acc,GateList)  goes  through  **/ 
/**  each  entry  of  WireList  looking  for  an  output  pin.  **/ 

/**  Once  an  output  pin  is  located,  get.gates  then  searches  **/ 
/**  for  the  corresponding  input  pins.  In  the  case  of  **/ 

/**  devices  with  more  than  one  output,  all  constituent  **/ 
/**  input  and  output  pins  are  located.  Once  a  pin  is  **! 

/**  located  the  corresponding  wire  name  (expressed  as  a  **/ 
/**  variable)  is  determined.  The  logic  function  of  the  **/ 
/**  particular  device  owning  the  pins  is  determined  and  a  **/ 
/**  corresponding  gate  is  formed.  The  gate  is  described  as  **/ 
/**  a  Prolog  term  with  the  logic  function  as  the  functor,  **/ 
/**  the  input  pin  wire  names  as  input  arguments,  and  the  **/ 
/**  the  output  pin  wire  name  or  wire  names  (multiple  **/ 

/**  outputs) as  output  arguments.  For  example  a  integrated  **/ 
/**  circuit  whose  type  was  SN7400  with  Wirel  on  pin  1,  **/ 

/**  Wire2  on  Pin2,  and  Wire3  on  Pin3  would  be  expressed  as  **/ 
/**  nand(_51,_52,_53)  where  _51  represents  Wirel,  _52  **/ 

/**  Wire2,  and  _53  Wire3.  **/ 

get_gates([]  ,_,_,[]). 

/**  This  rule  is  for  five-element  WireList  entries  **/ 

/**  describing  a  combinational  device.  **/ 
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get_gates(C[Naine,SIC,OutPin,_,_] |Xs] ,WireList,Acc, [GateiRest])  : 
not  var_member(Name,Acc) , 
ic(SIC,Type) , 
not  memory (Type) , 
pins (Type, OutPin,InPinList) , 
get_in_wires(InPinList ,WireList,SIC,InVars) , 
insert_out_pin(InVars .Name.ArgList) , 
function(Type,Fcn) , 

Gate  =. .  [Fcnl ArgList] , 
get_gates(Xs,WireList, [NamelAcc] ,Rest) . 


/**  This  rule  is  for  three-element  WireList  entries  **/ 

/**  describing  a  combinational  device.  **/ 

get_gates( [[Name, SIC, OutPin] iXs] , WireList, Acc, [GateiRest]) 

'not  var.member (Name, Acc) , 
ic(SIC,Type) , 
not  memory (Type) , 
pins(Type, OutPin, InPinList) , 
get _ in.wires ( InPinList , WireList , SIC , InVars) , 
insert _out_pin(InVars, Name, ArgList) , 
function(Type,Fcn) , 

Gate  =. .  [Fen  I ArgList] , 

get_gates(Xs, WireList,  [NamelAcc] ,Rest) . 

/**  This  rule  is  for  five-element  WireList  entries  **/ 

/**  describing  a  memory  device.  **/ 

get_gates ([[Name, SIC, OutPin, _,_] IXs] , WireList , Acc, [GateiRest]) 
not  var.meraber (Name, Acc) , 
ic(SIC,Type) , 
memory (Type) , 

pins(Type,OutPinList, InPinList) , 
vai_  mber (OutPin, OutPinList) , 
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get_in_wires(InPinList ,WireList,SIC,InVars) , 
get_out_wires(OutPinList,WireList,SIC,OutVars) , 
function(Type,Fcn) , 

Gate  =. . [Fcnl [InVars .OutVars , [Qplus.NQplus]]]  , 
append(OutVars,Acc,NewAcc) , 
get.gates (Xs , WireList , NewAcc , Rest) . 

**/ 
**/ 


/**  This  rule  is  for  three-element  WireList  entries 
/**  describing  a  memory  device. 


get_gates( C [Name, SIC, OutPin] IXs] , WireList, Acc, [GatelRest]) 
not  var_member(Name,Acc) , 
ic(SIC,Type) , 
memory (Type) , 

pins(Type,OutPinList ,InPinList) , 
var_raember(OutPin,OutPinList) , 
get.in.wires (InPinList , WireList , SIC , InVars) , 
get _out_Hires (OutPinList, WireList , SIC, OutVars) , 
function(Type,Fcn) , 

Gate  =. . [Fcnl [InVars , OutVars , [Qplus ,NQplus]]] , 

appendCOutVars , Acc, NewAcc) , 

get .gates (Xs , WireList , NewAcc , Rest) . 


/**  This  rule  discards  WireList  repeat  entries.  **/ 

get_gates([XlXs] , WireList, Acc, Ans) 
get_gates(Xs, WireList, Acc, Ans) . 

/*********+******♦*************+♦****♦**********************♦/ 
/**  get.in.wires (InPinList, WireList, SIC, Names)  looks  through**/ 
/**  WireList  for  each  occurrence  of  the  source  integrated  **/ 
/**  circuit  (SIC)  and  one  of  the  members  of  the  InPinList.  **/ 
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/+*  Each  time  a  match  is  found,  the  variable  name  of  the  **/ 
/**  connecting  wire  is  added  to  the  list  of  names.  **/ 

get_in_wires 

get_in_wires(CX|Xs] ,WireList,SIC,[Name|Names]) 

(member ( [Name , _ , _ ,SIC , X] .WireList) 

I 

member ( [Name, S I C,X] .WireList)) , 
get_in_wires(Xs .WireList, SIC, Names) . 

/**  if  the  interpreter  fails  to  find  a  wire  name  for  an  *♦/ 
/**  input  then  there  are  problems.  No  floating  inputs  are  **/ 
/**  allowed.  **/ 

get_in_wires([X|Xs] ,_,SIC,_) 

write( ’WARNING:  FLOATING  INPUT  ’),nl, 
write(X) ,write( ’  of  ’), 

write(SIC) ,write(’  is  not  connected. ’) ,nl, 

write (’Correct  the  wire  list  and  restart  the  process. ’) ,nl, 

halt . 


/*^(**!(c#!(l!(t  +  :tc*****#*3(c:(t**:)c*  +  *******J(t^:J)c**J<t*************  ***»*  +  ♦**:(:/ 

/**  get_out_wires(OutPinList, WireList, SIC, Names)  looks  **/ 
/**  through  WireList  for  each  occurrence  of  the  source  **/ 
/**  integrated  circuit  (SIC)  and  a  member  of  OutPinList.  **/ 
/**  Each  time  a  match  is  found,  the  variable  name  of  the  **/ 
/**  connecting  wire  is  added  to  the  list  of  wires  (Names) .  **/ 
/**  get_out_wires  is  used  by  devices  with  multiple  output  **/ 
/**  capabilities  such  as  flip-flops.  **/ 
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get_out_wires 

get_out_wires(CX|Xs] ,WireList,SIC, [Name I Names]) 

(member ( [Name , SIC , X , _ , .WireList) 

» 

memberC [Name, SIC, X] , WireList)) , 
get_out_wires(Xs , WireList , SIC, Names) . 

/**  if  an  available  output  is  not  used,  fill  it  with  a  **/ 

/**  place  holder.  This  is  analogous  to  a  floating  output.  **/ 

get_out_wires([XlXs] , WireList, SIC, [ZiNames]) 
get_out_wires(Xs , WireList , SIC, Names) . 

/**  insert_out_pin(InPins ,QutPin,PinList)  inserts  the  **/ 

/**  output  pin  (OutPin)  into  the  list  of  input  pin  **/ 

/**  arguments  (InPins) .  OutPin  is  inserted  at  the  end  of  **/ 

/**  the  list  as  by  convention,  the  input  arguments  to  any  ♦*/ 

/**  device  are  listed  first,  insert.out.pin  is  used  for  **/ 

/**  combinational  devices  only.  **/ 

insert_out_pin( [X] , OutPin , [X , OutPin] ) . 
insert_out_pin([X|Xs] , OutPin, [XjRest]) 
insert_out_pin(Xs , OutPin, Rest) . 

/**  get_inargs(WireList ,Acc,InArgs)  goes  through  WireList  **/ 
/**  and  finds  each  arity  three  entry  which  has  an  input  pin  **/ 
/**  as  its  third  argument.  This  can  only  be  an  input.  The  **/ 
/**  list  of  input  arguments  returned  to  the  invoking  procedure**/ 
/**  is  in  a  forward  order  reflecting  the  order  of  appearance**/ 
/**  of  input  wire  variable-names  encountered  as  the  procedure**/ 
/**  searched  through  WireList.  Note  that  the  procedure  **/ 

/**  will  backtrack  off  the  procedure  "pins"  looking  for  an  **/ 
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/**  in-pin  list  (InPinList)  of  which  Pin  is  a  member.  Also  **/ 
/**  of  interest  is  the  accumulator.  In  thic  procedure,  the  **/ 
/**  contents  of  the  accumulator  are  used  to  accumulate  the  **/ 
/**  v.iriable  names  of  those  input-wires  which  have  been  *■*/ 
/**  previously  discovered.  Upon  discovery  of  a  new  input-  **/ 
/**  wire  name,  a  comparison  is  made  with  the  contents  of  **/ 
/*■*  the  accumulator  and  if  the  input-wire  was  previously  **/ 
/♦*  discovered,  it  is  rejected.  This  prevents  the  same  wire  **/ 
/**  name  from  appearing  more  than  once  in  the  final  list  of  **/ 
/**  input  wire-names.  When  the  procedure  reaches  the  base-  **/ 
/**  case,  the  empty  list  is  returned  as  a  "seal”  on  the  list**/ 
/**  of  input  wire-names.  The  list  is  then  returned  in  the  **/ 
/**  proper  order  and  the  contents  of  the  accumulator  are  **/ 
/**  discarded.  This  technique  is  known  as  constructing  a  **/ 
/**  list  "bottom-up"  and  is  used  in  several  other  procedures.**/ 


get_inargs([] ,Acc,  []) . 

get_inargs( CCName,SIC,Pin] IRest] ,Acc, [NamelArgs])  :- 
ic(SIC,Type) , 
pins (Type , _ , InPinList) , 
member (Pin, InPinList) , 
not  var_member(Name,Acc) , 
get_inargs(Rest , [NamelAcc] ,Args) . 

get_inargs(CXIXs] ,Acc,Args)  :- 
get_inargs(Xs,Acc,Args) . 


/******  +  *****  +  !(c***!(t**!(c***J(c********#*1t*****  +  *j)c#*^<*********:(c****/ 

/**  get_outargs(WireList,Acc,OutArgs)  goes  through  WireList  **/ 
/**  and  finds  each  arity  three  entry  which  has  an  output  pin**/ 
/**  as  the  third  argument.  This  can  only  be  an  output.  The  **/ 
/**  list  of  output  arguments  is  returned  with  an  ordering  **/ 
/**  which  represents  the  order  of  appearance  of  the  output  **/ 


/*■*  wires  in  WireList.  Note  that  the  list  is  built 
/**  "bottom-up" . 


*■*/ 


get.outargs  ( [] ,  Acc ,  [] ) . 

get_outargs(  [[Name, SIC, Pin] I  Rest] ,Acc, [NamelArgs]) 
ic(SIC,Type) , 
pins(Type,Pin,_) , 
not  var_member (Name, Acc ) , 
get_outargs(Rest, [Name  I Acc] ,Args) . 

get_outargs([X|Xs] ,Acc,Args) 
get_outargs(Xs ,Acc,Args) . 


/**  get_q_args(GateList,QArgs)  finds  each  occurrence  of  a  *♦/ 
/**  memory  device  in  GateList  and  extracts  the  devices  **/ 
/**  arguments.  These  arguments  are  in  the  form  of  three  **f 
/**  lists  CCJ,K]  ,  [C|,NotQ] ,  CQ+,NotQ+]]  .  The  J,K  list  is  **/ 
/**  stripped  off  as  this  does  not  carry  any  information  **/ 
/**  which  has  state-to-state  significance.  The  other  two  **/ 
/**  lists  are  kept.  The  present-state  and  the  next-state  do**/ 
/**  have  a  temporal  significance  and  must  be  represented  in**/ 
/**  the  head  of  the  circuit  specification  as  well  as  in  the**/ 
/**  circuit  body.  These  two  lists  provide  the  vehicle  for  **/ 
/**  the  propagation  of  state-to-state  information  and  **/ 

/**  provide  the  capability  to  simulate  the  memory  function.**/ 


get_q_args([]  ,[]). 
get_q_args ( [X I Xs] , [Rmdr I  Rest] )  : - 
X  = . . [Functr | Args] , 
f unction (Type, Functr) , 
memory(Type) , 

Args  =  [InArgs I Rmdr] , 
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get_q^args(Xs,Rest) . 


get_q_args ( [X I Xs] , Dummy)  ; - 
get_q_args(Xs, Dummy) . 


/*******************************♦*:(!*****♦***  **  +  *♦*  **♦*♦****♦*/ 
/**  evalua-ce.circuitdnputList, States, Count  OutPutList)  first**/ 
/**  obtains  a  copy  of  the  previously  asserted  circuit-head  **/ 
/**  Head.  Head  specified  the  structure  which  would  be  **/ 

/**  needed  in  order  to  successfully  query  the  previously  **/ 
/**  developed  and  asserted  definition  of  the  test  circuit.  **/ 
/**  descriptor(circuit(InList,OutList,QList))  retrieves  the**/ 
/**  correct  structure  with  labels  for  future  manipulation.  **/ 
/**  update_states(QList .States ,NewStates)  swaps  the  future**/ 
/**  .state-list  of  States  with  the  present  state-list  of  **/ 
/**  QList.  If  this  is  the  initial  run  through  the  **/ 

/**  simulation,  this  clears  all  memory  devices.  If  this  is  **/ 
/**  any  other  cycle,  update.states  replaces  the  old  present**/ 
/**  -state  values  with  the  new  future-state  values  thereby  **/ 
/**  setting  up  the  memory  devices  for  the  next  cycle.  **/ 

/**  Head  is  now  respecified  as  having  the  same  functor  but  **/ 
/**  the  input  sequence  as  the  first  cirgument,  the  still  **/ 
/**  uninstantiated  output  list  (OutList) ,  and  the  partially**/ 
/**  instantiated  list  of  memory  arguments  (MewStates) .  **/ 

/**  Head  is  now  ready  for  this  particular  simulation  cycle.**/ 
/**  test_circuit(Head,NextStates, Output)  invokes  Head  as  **/ 
/**  an  executable  goal  and  instantiates  all  remaining  **/ 
/**  variables.  NextStates  can  now  be  extracted  to  be  used  **/ 
/**  to  setup  the  memory  devices  for  the  next  cycle  and  the  **/ 
/**  list  output  represents  the  simulated  circuit  result  for**/ 
/**  the  particular  input  list.  The  simulation  is  repeated  **/ 
/**  until  the  list  of  input  values  is  exhausted.  Count  is  **/ 
/**  to  keep  track  of  the  number  of  iterations  and  has  no  **/ 
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/**  bearing  on  the  simulation  process  except  to  inform  the  **/ 
/**  user  of  the  output  values  for  a  particular  clock  cycle.**/ 

evaluate.circuit ( [] , States 

evaluate_circuit( [X iXs] .States .Count ,  [Output [Rest] ) 
descriptor (circuit (InList . OutList .QList) ) . 
update_states(QList .States .NewStates) . 

Head  =. . ['circuit’ I [X. OutList. NewStates]] . 
test_circuit(Head.NextStates .Output) . 

Count 1  is  Count  +  1. 

tab(5) .write(Countl) .tab(lO) .  /**  formats  output**/ 
write(X) .tab(19) . 
write(Output) ,nl. 

evaluate_circuit(Xs .NextStates .Countl .Rest) . 

/*!((**+%*  +  *  ##:(!##*****#**:(c**j(c  #:(<!*!**♦*****♦***  :((*******♦♦  #*****♦**#/ 


/**  update.states (QList. States. NewStates)  takes  the  list  **/ 
/**  QList  (which  has  the  form  [X.Y]  where  both  X  and  Y  are  **/ 
/**  themselves  lists)  and  the  list  States  (which  has  the  **/ 
/**  same  general  form  as  QList)  and  constructs  a  new  list  **/ 
/**  called  NewStates  which  contains  the  second  list  of  **/ 
/**  States  followed  by  the  second  l.ist  of  QList.  The  **/ 
/**  contribution  from  States  is  critical  and  represents  the  **/ 
/+*  next-state  values  of  the  previous  simulation  cycle.  **/ 
/**  These  are  used  as  the  present-state  values  for  the  next  **/ 
/**  QList  contributes  two  variables  which  have  no  **/ 
/**  significance  other  than  place  holders  for  future  **/ 
/**  instantiations.  This  swapping  action  acts  to  clear  all  **/ 
/**  memory  devices  on  initial  entry  in  to  the  procedure.  **/ 
/**  subsequent  iterations  up-date  each  memory  device  by  **/ 
/**  discarding  the  old  present-state  values  and  replacing  **/ 
/**  them  with  the  next-state  values.  **/ 
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updat6_states(  []  ,[].[]). 


update_states( [[W,X] |Xs] , CCY,Z] |Zs]  ,[[Z,X] [Rest]) 
update_states (Xs , Zs . Rest) . 

/******^(^c*******:(c!(t*******^*=('!t:********:f:*  ♦**************+.  ***#*¥/ 


/**  test_circuit(Head,NextStates, Outputs)  executes  the  **/ 
/**  present  cycle’s  partial  instantiation  of  Head.  Head  **/ 
/**  is  fully  instantiated  after  execution  and  those  **/ 
!**  portions  (structures)  of  interest  (NextStates  and  **/ 
/**  Outputs)  are  extracted.  **/ 


test_circuit (Head .NextStates , Output)  : - 
goal (Head) , 

Head  =..[_ 1  [_ .Output .NextStates]] .  /**0nly  keep  the  pieces**/ 

/**of  interest.  **/ 

/:(i  *♦*:*(#*******♦*♦>;♦*♦*♦***************♦**  ****♦***************/ 

/**  goal(Goal)  executes  Goal  and  returns  the  results  **/ 

/**  implicitly  tr  test.circuit .  When  Goal  is  invoked,  some  **/ 
/**  of  its  arguw^nts  are  not  instantiated.  After  **/ 

/**  invocation,  all  of  its  variables  are  instantiated  and  **/ 
/**  although  they  are  not  passed  directly  to  test.circuit,  **/ 
/**  they  are  available  to  test_circuit  because  both  goal  **/ 
/**  and  test_circuit  are  on  the  same  stack.  **/ 

goal(Goal) 

Goal. 

/******  +  »;:(t******Jti:)c***)(i***************1c******;(c***!(c:([:(c**:(t))[4[*****/ 

/**  unite_circuit(Head,GateList, Circuit)  constructs  an  **/ 
/**  executable  Prolog  rule  by  uniting  Head  with  GateList.  **/ 

unite_circuit(Head,GateList , (Head:-  Lst)) 
goals_to_list(Lst,GateList) .  /*  running  it  backwards*/ 
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/********************)t!***:t!*****************^t***:tc***:t!**  ****♦**/ 

j**  var_member(X,List)  determines  if  the  variable  X  is  a  **/ 
/**■  member  of  the  list  List.  This  works  similar  to  the  **/ 
/**  conventional  member  procedure  with  the  exception  that  **/ 
/**  strict  equivalence  is  required.  **/ 

var_member(X, CY|_]) 

X==Y. 

var .member (X, C_ I Ys] ) 
var_member(X,Ys) . 

/*^c*********3t::ti******»**;tc**^*****:(c:4c*!(t:*c;)(***:)t*****  ***********♦**/ 

/**  the  conventional  member  procedure.  **/ 

member (X, [XlXs] ) . 
member (X, [YlYs] ) 
member(X,Ys) . 

/****#*:f;*:(i;^<****3(l******!(!}(c****»;*  +  ******^*********:(c*»*^*****^tJtc*;(t/ 

/**  the  conventional  append  procedure.  **/ 

append ( [] , X ,X) . 
append([X|Xs] ,Ys, [XIZs]) 
append(Xs,Ys,Zs) . 

/******#*^*********!tt***!*:**3(!******:(t**  +  *  +  *****i(C***  +  ***!([*!(C**^t^^*/ 

/**  pretty.printCList)  prints  lists  to  the  screen  with  a  *♦/ 
/*•*  more  readable  style.  **/ 

list.printC  [] ) . 
list.printCCXIXs]) 
tab(5) ,write(X) ,nl, 
list_print(Xs) . 


/***#*******************;(<;**^:,.**-j-he  End***********************/ 
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/  *********  ***********+***-t;-c]_cjat  a.  pro*****  ***************  *♦=*=****/ 
/**  The  following  information  was  taken  from  a  7400  series  **/ 
/**  TIL  data  book.  **/ 


/*.**********************************************:)[** j)i****!tc*  .*/ 


/**  pins (Type, OutPin,ListOf Inpins)  describes  the  pin  **/ 
/**  configuration  of  each  integrated  circuit  in  the  **/ 
/**  data-base.  This  information  is  used  to  determine  **/ 
/**  circuit  connectivity.  **/ 


pins (’7400’ ,pin3, Cpinl,pin2] ) . 
pins(’7400’ ,pin6, [pin4,pin5]) . 
pins (’7400’ ,pin8, Cpin9,pinl0]) . 
pins (’7400’ ,pinll , Cpinl2,pinl3] ) . 

pins(’7402’ ,pinl, Cpin2,pin3]) . 
pins(’7402’ ,pin4, [pinS.pinO]) . 
pins(’7402’ ,pinl0, Cpin8,pin9]) . 
pins(’7402’ ,pinl4, Cpinl2,pinl3] ) . 

pins (’7404’ ,pin2, [pinl]) . 
pins (’7404’ ,pin4, Cpin3]) . 
pins ( ’ 7404 ’ , pin6 , CpinS] ) . 
pins (’7404’ ,pin8, Cpin9]) . 
pins(’7404’ ,pinl0, [pinll] ) . 
pins( ’7404’ ,pinl2, [pinl 3] ) . 

pins (’7408’ ,pin3, [pinl,pin2] ) . 
pins(’7408’ ,pin6, [pin4,pin5] ) . 
pins(’7408’ ,pin8, Cpin9,pinl0]) . 
pins(’7408’ , pinll, [pinl2,pinl3] ) . 


pins(’7410’ ,pinl2, Cpinl,pin2,pinl3]) . 
.pins(’7410’ ,pin6, Cpin3,pin4,pin5]) . 
pins (’7410’ ,pin8, [pin9,pinl0,pinii]) . 

pins(’7432’ ,pin3, [pinl ,pin2] ) . 
pins(’7432’ ,pin6, [pin4,pin5] ) . 
pins(’7432’ ,pin8, Cpin9,pinl03 ) . 
pins(’7432’ ,pinll, [pinl2,pinl3] ) . 

pins (’7486’ ,pin3, [pinl,pin2]) . 
pins(’7486’ ,pin6, Cpin4,pinS]) . 
pins ( ’ 7486 ’ , pin8 , Cpin9 , pinlO] ) . 
pins(’7486’ ,pinll ,  [pinl2,pinl3] ) . 

pins (’74109’ , [pin6,pin7] , [pin2,pin3]). 
pins (’74109’ ,  [pinl0,pin9] , [pinl4,pinl33) . 


i**  functiondype, Function)  denotes  which  type  of  »»/ 
/**  integrated  circuit  performs  which  type  of  logic  ♦*/ 
/♦*  function.  **/ 


function(’7400’ ,nand) . 
function(’7402’ ,nor) . 
function(’7404’ ,inv) . 
function(’7408’ ,and) . 
function(’74l0’ ,nand) . 
function (’7432’ ,or) . 
function( ’7486’ ,xor) . 
function( ’74109’ , jkbar) . 


/ *♦♦**♦******»**♦♦♦***♦»***•»★**** *«***»«^»» **»*»» ***********/ 
/♦»  memory (Type)  lists  those  devices  which  belong  to  the  ♦•/ 
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/**  general  class  of  devices  capable  of  performing  a 
/**  memory  function. 


**/ 

**/ 


memory (’74109’) . 


f**  The  following  information  describes  gate  level  **/ 
/*♦  operation.  *#/ 

h*  jkbarC [Jln.Kin]  ,  [Q.QBar]  ,  [Q+,Q+Bar] )  **/ 
/**  jkbar  is  always  queried  with  [J.K]  instantiated;  hence  **/ 
/**  no  cuts  are  necessary.  **/ 


jkbar ([0,0] [0,1]) .  /**  next-state  low  **/ 

jkbar( [1,1] ,[_,_] ,[1,0]).  /**  next-state  high  **/ 

jkbar( [0, 1]  ,  [Q,QBar]  ,  [Q,QBar] ) .  /**  no  change  *^^/ 
jkbar([l,0] , [q,QBar] ,  [QBar,q]) .  /**  toggle  **/ 

/*t  three-input  nand-gate  operation.  **/ 

nandd,  1,1,0)  !. 

nand(_, _,_,!) . 

I**  two-input  nand-gate  operation.  **/ 

nand(l,l,0)  :-  ! . 
nand(_,_,l) . 

/**  two-input  and-gate  operation.  **/ 
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andd.l.l)  !. 
and(_,_,0) . 

f 

/**  two-input  nor-gate  operation.  **/ 

I 

nor(0,0, 1)  :■  !  • 

nor(_,_,0) . 

/**  two-input  xor-gate  operation.  **/ 

xor(A,B,l)  :■ 
diff(A,B), 

I , 

I 

xor(_,_,0) . 

I 

i 

/**  two-input  or-gate  operation.  **/ 

•  i 

or(0,0,0)  :-  ! . 
or(_,_,l) . 


/**  inverter  operation.  **/ 

inv(0,l) • 

inv(l,0) . 

/*******:i!**!(c*******#*:tc##*:tr***^7HE  END********** V*************/ 
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Appendix  C.  Specialization  Code  and  Test  Results 

C.l  Specialization  Code 

C.l.l  Scan,  Analyze,  and  Specialize  Code 

/lt;;f**#**#**!(t*****!(c**!(!***:(c*;(!*******  +  ***!H*:(c  +  *)|;****!)t*:(tj(c***Jt:;(c!(c****  +  ;)t/ 

/**  speccode.pro  **/ 

/**  This  file  contains  the  Prolog  code  necessary  to  carry  out  **/ 
/**  the  process  of  specialization  as  described  in  Clocksin’s  **/ 
/**  articles  on  the  subject.  Only  the  primary  procedures  are  **/ 
/**  defined  here.  Ancillary  helper  procedures  are  defined  in  **/ 
/**  the  files  named  routines. pro  and  listutil.pro.  **/ 

/***J(c!)c******!((*))c})t********%#****  +  *********!)c;J:*******^*#*:)t**  ****!((#**/ 

/****^c***i(t********>)t**(;ode  starts  hefe+*****=('-i'*******************/ 

/.**  scan(Head)  starts  the  specialization  process  by  breaking  **/ 
/**  down  the  upper-level  of  the  circuit  and  determining  if  **/ 
/**  specialization  can  be  applied.  The  head  and  goal  arguments**/ 
/**  are  broken  down  and  compared  to  find  any  out  arguments  **/ 
/**  which  are  not  being  used.  All  internal  variable  arguments  **/ 
/**  are  instantiated  using  the  routine  gensym.pro  during  this  **/ 
/**  check.  Unmatched  arguments  are  into  the  database  **/ 

/**  for  future  use.  Input  goal  arguments  are  also  asserted  for**/ 
/**  future  use  in  determining  outputs  which  are  fanned  to  **/ 
/**  other  modules.  **/ 

scan(Head) 

Head  =. . [PredIHeadArgs] , 

write (’HeadArgs  =’) , write (HeadArgs) ,nl, 

clause(Head,Body) , 

writeC’Body  =’) »write(Body) ,nl, 

goals_to_list (Body .Goals) , 

writeC ’Goals  =’ ) ,write(Goals) ,nl , 

args'_direction (Goals ,  []  ,  C]  .GoalArgsIn.GoalArgsOut) , 
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writeC’GoalArgsIn  =') ,write(GoalArgsIn) ,nl, 

write ( ’GoalArgs'Out  =’ ) , write (GoalArgsOut)  ,nl , 

unmatched(GoalArgsIn,GoalArgsOut,HeadArgs, [] .Unmatched) , 

write (’Unmatched  =’) .write (Unmatched) ,nl, 

assert (args (Unmatched)) . 

write(’ asserting  ’) .write (GoalArgsIn) ,nl, 

assert (inargs(GoalArgsIn)) , 

analyze(Goals , [] .Circuit) , 

write (’Circuit  =’) ,write(Circuit) . 


/**  analy2e(Goals,Acc. Circuit)  is  passed  the  goals  of  any  higher  **/ 
/**  level  circuit  for  further  processing.  Goals  are  separated  into  **/ 
/**  those  which  do  not  have  unmatched  out  arguments  and  those  who  **/ 
/**  do.  A  goal  found  to  contain  an  unmatched  out  argument  is  ■  **/ 


/**  immediately  sent  to  specialize  to  be  processed  further.  Once  the  **/ 
/**  specialized  version  of  the  matched  goal  is  returned,  it  is  added  **/ 
/**  to  the  original  list  of  goals  in  place  of  the  original  goal.  The  **/ 
/**  modified  list,  which  now  contains  all  original  goals  which  did  not**/ 
/**  have  unused  outputs  and  the  specialized  version  of  those  who  did.**/ 
/**  is  sent  through  analyze  again  in  order  to  propagate  the  removal  **/ 


/**  through  the  hierarchy.  Analyze  continues  this  cycle  until  all  **/ 
/**  goals  present  in  the  accumulator  have  all  outputs  utilized.  **/ 
/**  analyze(C3 .Acc.NewHead)  is  evoked  when  the  list  of  unprocessed  **/ 
/**  goals  is  empty.  The  head  of  the  old  rule  is  replaced  with  a  **/ 
/**  new  head  to  signify  that  it  is  a  specialized  version.  The  **/ 


/**  arguments  for  the  new  head  are  properly  configured  and  then  united**/ 
/**  with  the  list  of  goals  in  Acc.  Finally  the  direction  for  the  new  **/ 
/**  circuit  is  configured  and  asserted  into  the  database.  **/ 

/**  analyze([] .Acc.NewHead) . 

/**  This  section  configures  the  new  head  and  it  arguments.  Once  found.  **/ 
/**  the  new  head  is  attached  to  the  goals  in  Acc  and  asserted  into  the  **/ 
/**  database.  The  direction  is  also  asserted  for  future  reference.  **/ 
/**  This  is  a  recursive  procedure  and  is  evoked  each  **/ 
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/**  time  a  level. of  the  circuit’s  hierarchy  is  processed,  starting  with**/ 
/**  the  lowest  or  base  level  and  working  up.  NewHead  is  the  name  of  the**/ 
/**  replacement  head  generated  for  the  highest  level  specialized.  This  **/ 
/**  is  then  returned  to  scan.  **/ 

analyze ([] ,Acc, NewHead) 

write ( ’Finishing  up  in  analyze’) ,nl, 
write(’Acc  =  ’ ) ,write(Acc) ,nl, 
args_direction(Acc, [] , [] ,ArgsIn,ArgsOut) , 
writeC’ArgsIn  =  ’) ,write(ArgsIn) ,nl, 
write (’ArgsOut  =  ’ ) ,write(ArgsOut) ,nl, 
remove_dups(ArgsIn, [] .Tempi) , 
remove.dups (ArgsOut,  [] ,Temp2) , 
rrav_all_dups (Tempi ,Temp2,  □  , [] ,HInArgs,HOutArgs) , 
write(’HInArgs  =  ’ ) ,write(HInArgs) ,nl, 
write (’HOutArgs  =  ’) .write (HOutArgs) ,nl, 
append (HInArgs , HOutArgs .NHArgs) , 
write (’NewArgs  =  ’ ) ,write(HHArgs) ,nl, 
gensym(foo,X) , 

NewHead  =. . [XlNHArgs] , 

write(’ NewHead  =  ’) ,write(NewHead) ,nl, 

scan_acc(Acc,NewAcc) , 

unite (NewHead, NewAcc.Ans) , 

write(’ asserting  ’) ,write(Ans) ,nl, 

assert(Ans) , 

retract (inargs (Temp)) , 

write( ’retracting  ’)  ,write(Terap) ,nl, 

assert(direction(NewHead, HInArgs .HOutArgs)) , 

write(’ asserting  direction’) ,write( ’ (’) .write (NewHead) , 

write( ’ , ’ ) .write (HInArgs) .write( ’ . ’ ) .write(HOutArgs) . 

write(’) ’) ,write(’) ’) ,nl. 


**/ 


/**  analy ze (Goals, Acc, Circuit) . 

/**  This  level  of  analyze  looks  at  each  goal  to  see  if  it  has  any 


/**  outputs  which  are  unused.  If  all  outputs  are  used,  then  the  goal  **/ 

/**  is  stored  in  Acc  for  future  use.  If  at  least  one  output  is  not  **/ 

/**  used  then  that  goal  is  passed  on  to  the  next  level  of  analyze  for**/ 

/**  more  processing.  **/ 

cinalyze ([XI Rest]  , Acc, Circuit) 

writeC’In  analyze  1  ' ) ,write(X) ,nl, 
direction(X,InArgs .OutArgs) , 
args (Unmatched) , 

write ( ’Unmatched  args  =  ’) ,write(Unmatched) ,nl, 
not  matched(OutArgs , Unmatched) , 
analyze(Rest , [XI Acc] , Circuit) . 

/**  analyze(Goals , Acc , Circuit) .  **/ 

/**  The  single  goal  X  at  this  level  has  at  least  one  unused  output.  **/ 

/**  All  original  goals  which  occurred  prior  to  X  are  stored  in  Acc  and  **/ 
/**  either  they  don’t  have  unused  outputs  at  this  stage  in  the  process  or**/ 
/**  they  are  specialized  versions  of  previously  detected  goals  which  did,**/ 
/**  The  goal  X  is  sent  to  specialize  for  more  processing.  The  specialized**/ 
/**  version  is  returned  via  the  argument  Ans  and  appended  to  the  rest  of  **/ 


/**  the  yet  to  be  explored  list  "Rest".  This  effectively  replaces  the  **/ 
/**  old  predicate  goal  with  its  new  specialized  version.  This  list  is  **/ 
/**  then  added  to  the  Acc  and  the  process  started  all  over  again  as  **/ 
/**  deleted  outputs  in  the  specialized  goal  returned  via  Ans  could  have  **/ 
/**  propagated  back  to  affect  other  modules  at  the  same  level  in  the  **/ 
/**  hierarchy.  The  cycle  continues  until  all  modules  have  been  examined  **/ 
/**  at  least  once  and  no  unused  outputs  exist.  Note  that  a  module  may  **/ 


/**  be  either  primitive  or  high  level  at  this  point.  The  analyze  predicate**/ 
/**  is  not  interested  in  the  hierarchical  status  of  modules,  only  the  ▼■*/ 
/**  status  of  the  outputs.  **/ 


analyze( [X I  Rest] , Acc, Circuit) 

write(’In  analyze  2  ’ ) ,write(X) ,nl, 
direction(X,InArgs, OutArgs) , 


args (Unmatched) , 

writeC ’Unmatched  args  =  ’) .write (Unmatched) ,nl, 

matched(OutArgs .Unmatched) , 

specialize(X . Ans) . 

write(’Rest  =  ’) .write(Rest) .nl. 

write (’ Ans  =  ’ ) .write(Ans) .nl . 

append(Rest. Ans, Tempi) , 

write( ’Tempi  =  ’) ,write(Templ) ,nl, 

append(Acc, Tempi ,Temp2) , 

write(’Temp2  =  ’ ) ,write(Temp2) ,nl , 

analyze (Temp2, [] .Circuit) . 


/**  specialize(X,  [] ) .  **/ 
/**  This  rule  deals  with  the  modules  which  have  been  identified  as  **/ 
/**  having  at  least  one  unused  output  and  are  primitive.  Modules  of  **/ 
!**  this  type  are  deleted  from  this  level  of  the  hierarchy.  The  **/ 
/**  deleted  modules  input  port-designators  may  then  be  added  to  the  *■*/ 
/**  list  of  unmatched  arguments  provided  no  other  module  uses  that  **/ 
/**  designator  as  an  input.  The  predicate  check.args  handles  the  **/ 


/**  input -argument  processing  for  the  deleted  modules.  The  predicate  **/ 
/**  remove_dups  is  included  in  the  process  at  this  stage  in  order  to  **/ 
/**  improve  efficiency  by  removing  repeat  arguments  from  the  list  of  **/ 
/**  unmatched  arguments.  *+/ 

specialize(X, [] ) 

write(’In  specialize  1  ’ ) ,write(X) ,nl, 
direction(X,InArgs,OutArg) , 

X  = . . [Pred I Args] , 
primitive(Pred) , 
args (Unmatched) , 

write ( ’Unmatched  args  =’ ) ,write(Unmatched) ,nl , 
matched(OutArg, Unmatched) , 
inargs(StoredArgs) , 
check. args ( InArgs , [] , Ans , Stor edArgs ) , 
inargs (Stored) , 


write ( ’checking  inargs  ’) ,write(Stored) ,nl, 

append (Ans, Unmatched, Tempi) , 

remove.dups (Tempi, [] ,Temp2) , 

retract (args (Unmatched) ) , 

write( ’retracting  ’ ) , write (Unmatched) ,nl, 

write( ’asserting  all  Unmatched  args  ’) ,write(Temp2) ,nl , 

assert (args (Temp2)) . 

/**  specialize(X, CAns2] ) .  **/ 

/**  This  predicate  handles  those  goals  which  are  not  primitive  and  *■*/ 
/**  are  in  need  of  further  processing.  Mote  that  new  unmatched  **/ 

/**  arguments  are  added  to  the  list  of  old  unmatched  arguments  and  **/ 
!**  asserted  into  the  database.  A  common  list  of  unmatched  arguments**/ 
/**  is  kept  and  applied  to  all  layer?  of  the  hierarchy.  However,  the**/ 
/**  list  of  input  arguments  (inargs)  is  only  applicable  to  the  layer**/ 
/**  of  the  hierarchy  currently  being  worked.  These  arguments  are  kept**/ 
/**  in  the  proper  place  on  the  argument  stack  by  use  of  asserta.  **/ 
/**  Once  the  unmatched  arguments  and  the  new  input  arguments  have  **/ 
/**  been  added  to  the  database,  X  is  then  entered  into  for  processing**/ 
/**  at  the  next  lower  hierarchical  level.  **/ 

specialize(X, [Ans2] ) 

write(’In  specialize  2  ’) ,write(X) ,nl, 
direction(X,InArgs,OutArgs) , 

X  =. . [PredlArgs] , 

not  primitive(Pred) , 

write(’Pred  =  ’ ) ,write(Pred) ,ni , 

ciause(X,Body) , 

goals_to_list(Body, Goals) , 

write( ’Goals  =  ’ ) ,write(Goals) ,nl , 

args_direction(Goals , [] ,[] ,GoalArgsIn,GoalArgsOut) , 

unmatched(GoalArgsIn,GoalArgs0ut,Args,C3 ,MewUnmatched) , 

write( ’Unmatched  =  ’ ) ,write(NewUnmatched) ,nl,  args (Unmatched) , 

write (’looking  at  ’) ,write(Unmatched) ,nl, 
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asserta(inargs(GoalArgsIn)) , 

write (’asserting  the  following  Inargs  ’) ,write(GoalArgsIn) ,nl, 

append (Unmatched , NewUnmatched , Ans) , 

remove_dups(Ans , [] .UnmatchedArgs) , 

retractalKargs (Unmatched)) , 

write ( ’retracting  ’) .write (Unmatched) ,nl, 

write( ’asserting  ’), 

write (UnmatchedArgs) ,nl , 

assert(args(UnmatchedArgs)) , 

analyze(Goals , [] , Ans2) , 

write(’Ans2  =  ’ ) ,write(Ans2) ,nl . 


?-reconsult(gensym) . 
?-reconsult(listutil) . 
?-reconsult (routines) . 
?-reconsult(testcrts) . 


again 

reconsult (speccode) . 
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C.1.2  Specialized  Ancillary  Routines 


/********************  +  ****  +  **3)t*  +  ^t¥**:)c*****j(c******:(c*>(t***^!:(c*********:(":4!  +  *J|<*/ 

/**  routines. pro  **/ 

/**  Routines. pro  has  all  the  ancillary  routines  developed  specifically**/ 

/**  for  Clocksin’s  specialization  algorithm  to  work.  **/ 

/***************  +  ***>(!****  **********i(t!(c**^t******:(t*************  +  ***=t!****  +  **/ 

/**  check_args(InArgs,Acc,Ans,StoredArgs) . 

This  predicate  checks  the  input  arguments  of  a  module  which  is 
slated  to  be  deleted  to  see  if  any  particular  arguments  are  used 
elsewhere.  If  not,  then  that  particular  argument  can  be  added  to 
the  list  of  unused  arguments.  If  the  argument  fans  to  other 
modules,  then  it  can  not  be  removed.  However  if  all  the  other 
modules  which  use  that  particular  argument  are  subsequently  removed, 
then  the  argument  can  be  removed.  check_args  keeps  track  of  the 
number  of  modules  which  use  any  one  particular  argument  and  will 
allow  that  input  designator  to  be  added  to  the  list  of  unmatched 
arguments  only  when  the  argument  is  truly  unmatched.  **/ 

check_args(C] ,Acc,Acc,StoredArgs) . 

check_args(CX|Rest] ,Acc,Ans,StoredArgs) 
delete (X, StoredArgs , Tempi) , 
var_member(X, Tempi) , 
retract (inargs (StoredArgs)) , 
assertaCinargs (Tempi)) , 
check_args(Rest,Acc,Ans, Tempi) . 

check_args([X|Rest] ,Acc,Ans, StoredArgs) 
check_args(Rest, [XiAcc] ,Ans , StoredArgs) . 

/**  delete(X,L,Ans) . 

delete  X  from  L  to  give  an  answer  which  is  simply  the  list  L 
with  one  copy  of  X  deleted.  More  X's  may  or  may  not  exist  in 
Ans  when  delete  is  complete.  **/ 


delete (X,  [],□). 
delete(X,CX|L] ,L):- 


delete(X, [YlL] ,  [YlNewLst] ) 
delete(X,L,NewLst) . 


/**  matched(Listl,List2) . 

matched  checks  for  membership  between  two  lists.  If  any  element  of 
list!  matches  any  element  of  list2  the  match  succeeds.  **/ 

matchedCG  ,  []) . 
matchedCCX I  Rest] .Unmatched) 
var_member(X, Unmatched) , 

I 

•  9 

true. 

matchedC [X I  Rest] .Unmatched)  : - 
matched(Rest, Unmatched) . 

/**  remove_dups(List.Acc,Ans) . 

remove_dups  will  remove  any  repeating  elements  in  list  and  return 
individual  members  in  Ans.  **/ 

remove_dups(n .Acc.Acc) . 
remove_dups ( [X I  Rest] , Acc , Ans )  :  - 
var_member(X,Rest) . 
remove_dups(Rest.Acc,Ans) . 

r emove_dups ( [X I  Rest] , Acc , Ans )  : - 
not  var_member(X,Rest) , 
remove_dups(Rest. [XI Acc] .Ans) . 

/**  rmv_all_dups (List 1 ,List2,Accl. Acc2. Ansi .Ans2) . 
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rmv_all_dups  will  search  listl  and  list2  for  common  members. 
When  an  element  is  found  to  be  a  member  of  both  lists,  that 
element  and  all  other  occurrences  are  deleted  from  both  lists. 
The  new  lists  are  returned  in  Ansi  and  Ans2.  **/ 


nnv_all_di’,ps(  □  ,_,Accl  ,Acc2,Accl  ,Acc2)  . 
nnv_all_dups( [X iRest] , Out Args ,Accl ,Acc2, Ansi ,Ans2) : - 
var .member (X, Out Args) , 
delete (X, Out Args , Tempi) , 

rmv_all_dups (Rest .Tempi ,Accl .Tempi , Ansi ,Ans2) . 

rmv_ali_dups ( [X I  Rest] , OutArgs , Accl , Acc2 , Ans 1 , Ans2) ; - 
rmv_all_dups (Rest , OutArgs ,  [X I Acc 1] , OutArgs , Ansi , Ans2) . 


!**  args_direction(Listl, Accl, Acc2, Ansi, Ans2) . 

This  predicate  takes  a  list  of  goals  and  separates  their 
arguments  into  two  lists,  one  with  all  input  arguments  and  the 
other  with  all  output  arguments.  Input  arguments  are  accumulated 
in  Accl,  output  arguments  are  accumulated  in  Acc2.  **/ 

args_direction([] , Accl, Acc2, Accl, Acc2) . 
args_direction( [X I  Rest] , Accl , Acc2 , Argsin , ArgsOut) : - 
direction(X,InputArgs,OutputArgs) , 
append(InputArgs,Accl,NewAccl) , 
append(OutputArgs ,Acc2,NewAcc2) , 
args_direction(Rest .NewAccl ,NewAcc2, Argsin, ArgsOut) . 


/**  goals_to_list(listl,list2) . 

goals_to_list  converts  a  list  in  Prolog  internal  syntax  to  a  list 
which  resembles  more  conventional  list  notation.**/ 

goals_to_list(true,  □  )  !. 
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goals_to_list(’ , ’ (First, Rest) , [First IConvertRest] ) 

■  t 

goals_to_list(Rest .ConvertRest) . 
goals_to_list(Goal , [Goal] ) . 

/**  unmatchedCListl ,List2, Lists, Acc.Ans) . 

Unmatched  compares  List2  with  Listl  and  Lists  and  stores  any 
arguments  from  list2  which  do  not  appear  in  either  listl  or  lists 
in  Acc.  Any  variables  which  are  not  instantiated  are  fixed  with  a 
unique  instantiation  provided  by  gensym.  **/ 

unmatched(_ , [] ,_ ,Acc,Acc) . 
unmatched(GAIn, [XiRest] ,HeadArgs,Acc,Ans) 
writeC’  Looking  at  ’) ,write(X) ,nl, 
var(X) , 

(var_member(X,GAIn) ; 

■  var_member(X,HeadArgs)) , 

I 

•  f 

gensymC’T’ ,Y) , 

X=Y, 

unmatched(GAIn, Rest, HeadArgs , Acc, Ans) . 
unmatched(GAIn, [XiRest] , HeadArgs, Acc, Ans) 
nonvar(X) , 

(var_member(X,GAIn) ; 
var_raember(X, HeadArgs)) , 

I 

•  f 

unmatched(GAIn, Rest, HeadArgs , Acc, Ans) . 
unmatched(GAIn, [XiRest] , HeadArgs, Acc, Ans) 
gensym('T’ ,Y) , 

X=Y, 

unmatched(GAIn, Rest , HeadArgs , [XI Acc] ,Ans) . 

/**  var_raember(Element,List) . 

works  the  same  as  regular  membership  except  this  procedure  will 
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also  work  for  variables.  ♦*/ 

var .member (X, [Y I _3 ) 

X==Y. 

var .member (X , [_ I L] )  :  - 
var .member (X,L) . 

/**  scan.accCListl ,List2)  will  remove  all  terms  in  listl  which 
have  an  arity  of  zero  and  return  a  new  list,  List2  of  the 
surviving  terms .  **/ 

scan.accCG  ,[])- 

scan_acc(CX|Restl] ,Rest2) 

X  =. .  [Predl  []]  , 
scan_acc(Restl ,Rest2) . 

scan.accCCXlRestl] , CX|Rest2]) 
scan_acc(Restl ,Rest2) . 

/**  unite(Element,List,NewRule) . 

unite  will  connect  a  predicate  (NewHead)  with  a  set  of  goals 
(ValidGoals)  to  form  a  new  rule.  **! 

unite(NewHead,ValidGoals, (NewHead  ValidGoals))  !. 
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C.1.3  General  Utility  Programs 

/**  listutil.pro  **/ 

/**  All  procedures  listed  here  are  standard  utili', procedures.  **/ 
/**  used  by  the  files  speccode.pro  or  routines. pro.  **/ 

member (X,  [XL]) . 
member (X , [_ I  Tail] ) : - 
member (X, Tail) . 

append([] ,L,L) . 
append ( [X I Tail] , H , [X I XS] ) : - 
append (Tail, M,XS) . 
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C.1.4  Gensym  Code 


/:^^:^ifH!ilfif^t****^***********  GENSYM  .pro  ***!|t****)(!!t:!it!)t***)(t**  +  j|!^c**:t:H‘****/ 

/**  **/ 

/*■*  ’gensyra(Root,Atom) ’  creates  a  new  atom,  which  begins  with  **/ 
/**  the  specified  root  and  ends  with  a  unique  integer.  **/ 

/**  Typical  session:  **/ 

/**  ?-  gensym(foo,X) .  **/ 

/**  X  =  fool  **/ 

/**  More  (y/n)?  y  **/ 

/**  no  **/ 

/**  **/ 

/**  ?-  gensym(foo,X) .  **/ 

/**  X  =  foo2  **/ 

/**  More  (y/n)?  y  **/ 

/**  no  **/ 

/**  **/ 

/**  This  code  is  taken  from  the  Clocksin  &  Hellish  book,  **/ 

/**  Programming  In  Prolog,  Section  7.8.  **/ 

/jK*  **/ 

9|c  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3fC  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3fc  3^  3|C  3^  3^  3^  3^  34^  ^ 


gensym(Root,Atom)  :- 
get_num(Root,Nura) , 
name (Root ,Narael) , 
integer_name(Num,Name2) , 
append(Namel ,Name2,Name) , 
name (Atom, Name) . 

get_num(Root,Num) 

retract (current_num(Root , Numl )) , 

I 

•  f 

Num  is  Numl  +  1, 
asserta(current_num(Root,Num)) . 
get_num(Root,l) 
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asserta(current_num(Root , 1) ) . 


/*  Convert  from  ein  integer  to  a  list  of  characters.  */ 

integer_name(Int,List) 
integer_narae2(Int, [] .List) . 

integer_name2(I,SoFar, [CiSoFar]) 

I  <  10, 

I 

•  y 

C  is  I  +  48. 

integer_name2(I,SoFar,List) 

TopHalf  is  I  //  10,  /*  Some  Prologs  may  call  this  V’  */ 

BottomHalf  is  I  mod  10, 

C  is  BottomHalf  +  48, 
integer_name2(TopHalf ,  [CiSoFar] .List) . 

again 

reconsult (gensym) . 


?-  reconsult(listutil) .  /*  Needed  for  the  call  to  ’append’  */ 
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C.1.5  Prolog  Code  Dejiniticns  of  Test  Circuits 


!*■*  testcrt.pro  **/ 
/**  This  file  contains  Prolog  code  which  defines  several  **■/ 
/*  circuits  used  to  test  the  program  which  implements  **/ 
/%*  Clocksin’s  specialization  process.  **/ 


^  ^  ^  ^  ^  5|C  jjc  ^  ^  )|C  ^  ^  ^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3^  3|C  3|c  3^  3^  3^C  3^  343  3^^  34^  3^3  34c  3^3  3|C  3^3  3^3  *4^  34c  34c  34c  34C  34*  34^  34c  34^  34^  34c  34C  34^  34C  34C  ^ 

/**  Testl  uses  a  circuit  which  has  unused  primitive  gates  **/ 

/**  at  the  highest  level  in  the  hierarchy.  These  unused  **/ 

/*■*  primitive  gates  are  fed  by  other  hierarchical  modules.  **/ 

/**  which  may  or  may  not  need  to  be  specialized  when  the  **/ 

/**  unused  primitive  modules  are  removed.  **/ 

testl 

scan(circuitl(a,b,c,as,s,co)) . 

circuitl(A,B,C,As,S,Co) 
halfadd(B,C,Tl,T2), 
halfadd(A,Tl,S,Co) , 
xor_gate(A,As,T3) , 
and_gate(Tl ,T3,T4) , 
or_gate(T2,T4, Unused) . 

/**  Test  2  looks  at  a  circuit  which  has  a  hierarchical  **/ 

/**  module  consisting  of  other  hierarchical  and  primitive**/ 

/**  modules.  The  subordinate  hierarchical  module  does  not  **/ 

/**  have  any  unused  outputs  and  can  be  completely  eliminated.  **/ 

test2 

scan(circuit2(a,b,c,as,s,co)) . 

circuit2(A,B,C,As,S,Co) 
halfadd(B,C,Unusedl ,Unused2) , 
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halfadd(A,T3,S,Co), 
xor_gate(A,As,T3) . 


/**  Test  3  inputs  a  circuit  where  every  output  is  used  and  **/ 
/**  no  specialization  is  possible.  **/ 

test3 

scan(circuit3(a,b,c,as,s,co)) . 

circuit3(A,B,C,As,S,Co) 

halfadd(B,C,Tl,T2), 

halfadd(A,Tl,S,Co), 

•xor_gate(A,As,T3) , 
and.gate(Tl ,T3 ,T4) , 
or_gate(T2,T4,Co) . 

/**  Test  4  is  Clocksin’s  test  as  given  in  the  article  **/ 
test4 

scan(twobit(al ,bl ,a2,b2,c,as ,sl ,s2)) . 

twobit(Al ,B1  ,A2,B2,C,As,Sl ,S2) 
addsub(Al,Bl,C,As,Sl,T) , 
addsub(A2, B2,T, As ,S2, Unused) . 


addsub(A,B,C,As,S,Co) 
halfadd(B,C,Tl,T2), 
half add(A,Tl,S, Unused) , 
xor_gate(A,As,T3) , 
and_gate(Tl ,T3,T4) , 
or_gate(T2,14,Co) . 
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halfadd(A,B.S,C) 
xor_gate(A,B,S) , 
nand_gate(A,B,T) , 
nnot_gate(T,C) . 


/**  direction(Module,InputPorts,OutputPorts)  is  used  to  **/ 

/**  differentiate  input  from  output  ports,  direction  only  needs  **/ 
/**  to  be  defined  for  lower-level  generic  modules.  **/ 

direction(addsub(A,B,C,As,S,Co) ,  [A,B,C,As] , CS,Co]) . 
direction(halfadd(A,B,S,C) , [A.B] , [S,C] ) . 
direction(or_gate(A,B,Out) , [A.B] , [Out] ) . 
direction(xor_gateCA,B,Out) , [A.B] , [Out] ) . 
direction(and_gate(A,B»Out) , [A,B] , [Out] ) . 
direction(nnot_gate(A,B) , [A] , [B] ) . 
direction(nand_gate(A,B,C) , [A,B] , [C] ) . 

/**  primitive(Gate)  identifies  gates  which  are  at  the  lowest  **/ 
/**  level  of  the  circuit  hierarchy.  **/ 

primitive (or_gate) . 
primitive(xor_gate) . 
primitive (and.gate) . 
primitive(nnot_gate) . 
primitive(nand_gate) . 
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C.2  Specialization  Test  Results 


C.2.1  Test  1  Code  and  Results 


/**  testl  results  **/ 
/**  Testl  uses  a  circuit  which  has  unused  primitive  gates  **/ 
/**  at  the  highest  level  in  the  hierarchy.  These  unused  **/ 
/**  primitive  gates  are  fed  by  other  hierarchical  modules.  **/ 
/**  which  may  or  may  not  need  to  be  specialized  when  the  **/ 
/**  unused  primitive  modules  are  removed.  **/ 


/**!(t************j|!*)(!*'t:estl  circuit  definition****************/ 
testl 

scan(circuitl(a,b,c,as,s,co)) . 

circuitl(A,B,C,As,S,Co) 
halfadd(B,C,Tl,T2), 
halfadd(A,Tl ,S,Co) , 
xor_gate(A,As,T3) , 
and_gate(Tl,T3,T4) , 
or_gate(T2,T4, unused) . 

/**  The  following  generic  submodule  definitions  are  needed  to  **/ 
/**  define  the  subcircuit  structure  and  are  explained  in  **/ 
/**  section  C.1.5.  **/ 


halfadd(A,B,S,C) 
xor_gate(A,B,S) , 
nand_gateCA,B,T) , 
nnot_gate(T,C) . 
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direction(halfadd(A,B,S,C) , CA,B] , CS,C] ) . 
direction(or_gate(A,B,Out) , [A,B] , [Out] ) . 
direction(xor_gate(A,B,Out) , [A,B] , [Out]) . 
direction(and_gate(A,B,Out) ,  [A,B] , [Out] ) . 
direction(nnot_gate(A,B) , [A] , [B] ) . 
direction(nand_gate(A,B,C) , [A,B]  , [C]) . 

primitive(or_gate) . 
primitive(xor_gate) . 
primitive(and_gate) . 
primitive(nnot_gate) . 
primitive (nand.gate) . 

/ *  +  ;(t*****;*:**********:(c  +  **Xest  Results’t'************#**********/ 


Script  Vi.O  session  started  Mon  Oct  14  13:22:55  1991 

Microsoft(R)  HS-DOS(R)  Version  4.01 

(C)Copyright  Microsoft  Corp  1981-1988 

A : \THESIS\CODE>prolog 

+ - + 

I  MS-DOS  Prolog-1  Version  2.2  | 

I  Copyright  1983  Serial  number:  0001213  I 

I  Expert  Systems  Ltd.  I 

I  Oxford  U.K.  I 

+ - + 

?-  [speccode] . 
speccode  consulted. 

?-  testl. 

HeadArgs  =[a,b,c,as,s,co] 
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Body  =halfadd(b,c,_102,_103) ,halfadd(a,_102,s,co) ,xor_gate(a,as ,_118) , 
and_gate(_102,_118,_125) ,or_gate(_103,_125,_132) 

Goals  =[halfadd(b,c,_102,_103) ,halfadd(a,_102,s ,co) ,xor_gate(a,as,_118) , 
and_gate(_102,_ll8,_125) ,or_gate(_103,_125,_132)] 

GoalArgsIn  =[_103,_125,_102,_118,a,as,a,_102,b,c] 

Goal ArgsOut  =  C_ 132 , _ 125 , _ 1 18 , s , co , _ 102 , _ 103] 

Looking  at  _132 
Looking  at  _125 
Looking  at  _118 
Looking  at  s 
Looking  at  co 
Looking  at  _102 
Looking  at  _103 
Unmatched  =[T1] 

assert ing  [TS , T2 , T4 , T3 , a , as , a , T4 , b , c] 

In  analyze  1  halfadd(b,c,T4,T5) 

Unmatched  args  =  [Tl] 

In  analyze  1  halfadd(a,T4,s ,co) 

Unmatched  args  =  [Tl] 

In  analyze  1  xor_gate(a,as,T3) 

Unmatched  args  =  [Tl] 

In  analyze  1  and_gate(T4,T3 ,T2) 

Unmatched  args  =  [Tl] 

In  analyze  1  or_gate(T5,T2,Tl) 

Unmatched  args  =  [Tl] 

In  analyze  2  or_gate(T5,T2,Tl) 

Unmatched  args  =  [Tl] 

In  specialize  1  or_gate(T5,T2,Tl) 

Unmatched  args  =[T1] 

In  check_argsl 
X  =  T5 
Rest  ='  [T2] 
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stored  inargs  =  [T5,T2,T4,T3,a,as,a,T4,b,c] 
deleting  T5 

from  CT5,T2,T4,T3,a,as,a,T4,b,c] 

Tempi  =  [T2,T4,T3,a,as.a,T4,b,c] 
in  check.args  2 
adding  T5 
to  Acc  [] 

In  check_argsl 
X  =  T2 
Rest  =  [] 

stored  inargs  =  [T5,T2,T4,T3,a,as,a,T4,b,c] 
deleting  T2 

from  [T5,T2,T4,T3.a,as,a,T4,b,c] 

Tempi  =  [T5,T4,T3,a,as,a,T4,b,c] 
in  check.args  2 
■adding  T2 
to  Acc  [T5] 

checking  inargs  CT5,T2,T4,T3,a,as,a,T4,b,c] 
retracting  [Tl] 

asserting  all  Unmatched  args  [T1,T5,T23 
Rest  =  [] 

Ans  =  [] 

Tempi  =  [] 

Temp2  =  [and_gate(T4,T3,T2) ,xor_gate(a,as ,T3) ,halfadd(a,T4,s ,co) , 
half add (b,c,T4,T5)] 

In  analyze  1  and_gate(T4,T3,T2) 

Unmatched  args  =  [T1,T5,T2] 

In  analyze  2  and_gate(T4,T3,T2) 

Unmatched  args  =  CT1,T5,T2] 

In  specialize  1  and_gate(T4,T3,T2) 

Unmatched  args  =CT1,T5,T2] 

In  check.argsl 
X  =  T4 
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Rest  =  [T3] 

stored  inargs  =  CT5,T2,T4,T3,a,as,a,T4,b,c] 
deleting  T4 

from  CT5,T2,T4,T3,a,as,a,T4,b,c] 

Tempi  =  [T5,T2,T3,a,as,a,T4,b,c] 
checking  membership  of  T4 
In  [T5,T2,T3,a,as,a,T4.b,c] 
retracting  CT5,T2,T4,T3,a,as.a,T4,b,c] 
asserting  CT5,T2,T3,a,as,a,T4,b,c] 

In  check_argsl 
X  =  T3 
Rest  =  [] 

stored  inargs  =  CT5,T2,T3,a,as ,a,T4,b,c] 
deleting  T3 

from  [T5,T2,T3,a,as,a,T4,b,c] 

Tempi  =  [T5,T2,a,as,a,T4,b,c] 
in  check.args  2 
adding  T3 
to  Acc  □ 

checking  inargs  CT5,T2,T3,a,as,a,T4,b,c3 
retracting  [Tl , T5 , T2] 

asserting  all  Unmatched  args  CT2,T5,T1,T33 

Rest  =  Cxor_gate(a,as,T3),halfadd(a,T4,s,co),halfadd(b,c,T4,T5)] 
Ans  =  [] 

Tempi  =  [xor_gate(a,as,T3),halfadd(a,T4,s,co),halfadd(b,c,T4,T5)] 
Temp2  =  Cxor_gate(a,as,T3) ,halfadd(a,T4,s,co) ,halfadd(b,c,T4,T5)] 
In  analyze  1  xor_gate(a,as,T3) 

Unmatched  args  =  [T2,T5,T1,T3] 

In  analyze  2  xor_gate(a,as,T3) 

Unmatched  args  =  CT2,T5,T1,T3] 

In  specialize  1  xor_gate(a,as ,T3) 

Unmatched  args  =CT2,T5,T1,T3] 

In  check_argsl 
X  =  a 

Rest  =  [as] 


C-23 


stored  inargs  =  CT5,T2,T3,a,as,a,T4,b,c] 
deleting  a 

from  [T5,T2,T3,a,as ,a,T4,b,c] 

Tempi  =  [T5,T2,T3,as,a,T4,b,c] 
checking  membership  of  a 
In  CT5,T2,T3,as,a,T4,b,c] 
re  "acting  CT5,T2,T3,a,as,a,T4,b,c] 
asserting  CT5,T2,T3,as,a,T4,b,c] 

In  check_argsl 
X  =  as 
Rest  =  [] 

stored  inargs  =  [T5,T2,T3,as ,a,T4,b,c] 
deleting  as 

from  [T5,T2,T3,as,a,T4,b,c] 

Tempi  =  CT5,T2,T3,a,T4,b,c] 
in  check_args  2 
adding  as 
to  Acc  [] 

checking  inargs  CT5,T2,T3,as,a,T4,b,c3 
retract ing  CT2 , T5 , T1 , T33 

asserting  all  Unmatched  args  [T3,Tl,T5,T2,as] 

Rest  =  Chalfadd(a,T4,s,co) ,halfadd(b,c,T4,T5)] 

Ans  =  [3 

Tempi  =  [halfadd(a,T4,s ,co) ,halfadd(b,c,T4,T5)3 
Temp2  =  [halfadd(a,T4,s,co) ,halfadd(b,c,T4,T5)3 
In  analyze  1  halfadd(a,T4,s,co) 

Unmatched  args  =  [T3,T1 ,T5,T2,as3 
In  analyze  1  half add(b,c,T4,T5) 

Unmatched  args  =  [T3 , T1 , T5 , T2 , as3 
In  analyze  2  half add(b,c,T4,T5) 

Unmatched  args  =  CT3,T1 ,T5,T2,as3 
In  specialize  1  halfadd(b,c,T4,T5) 

In  specialize  2  halfadd(b,c,T4,T5) 

Pred  =  half add 

Goals  =  [xor_gate(b,c,T4) ,nand_gate(b,c,_1061) ,nnot_gate(_1061  ,T5)3 


Looking  at  T5 
Looking  at  _1061 
Looking  at  T4 
Unmatched  =  CD 
looking  at  [T3,T1 ,T5,T2,as] 
asserting  the  following  Inargs  CT6,b,c,b,c3 
retracting  [T3,Tl,T5,T2,as3 
asserting  Cas,T2,T5,Tl,T3] 

In  analyze  1  xor_gate(b,c,T4) 

Unmatched  args  =  [as,T2,T5,Tl,T3] 

In  analyze  1  nand_gate(b,c,T6) 

Unmatched  args  =  [as,T2,T5,Tl ,T3] 

In  analyze  1  nnot_gate(T6,T5) 

Unmatched  args  =  [as,T2,T5,Tl,T3] 

In  analyze  2  nnot_gate(T6,T5) 

Unmatched  args  =  Cas,T2,T5,Tl ,T3] 

In  specialize  1  nnot_gate(T6,T5) 

Unmatched  args  =Cas,T2,T5,Tl ,T3] 

In  check_argsl 
X  =  T6 
Rest  =  [] 

stored  inargs  =  CT6,b,c,b,c] 
deleting  T6 
from  [T6,b,c,b,c] 

Tempi  =  Cb,c,b,c] 
in  check. args  2 
adding  T6 
to  Acc  [] 

checking  inargs  [T6,b,c,b,c] 
retracting  [as,T2,T5,Tl,T3] 

asserting  all  Unmatched  args  CT3,Tl,T5,T2,as,T6] 
Rest  =  [] 

Ans  =  □ 

Tempi  =  □ 

Temp2  =  Cnand.gate(b,c,T6) ,xor_gate(b,c,T4)] 
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In  analyze  1  nand_gate(b,c,T6) 

Unmatched  args  =  [T3,Tl,T5,T2,as,T6] 

In  analyze  2  nand_gate(b,c,T6) 

Unmatched  args  =  CT3,Tl,T5,T2,as,T63 
In  specialize  1  nand_gate(b,c,T6) 

Unmatched  args  =[T3,Tl,T5,T2,as,T63 
In  check_argsl 
X  =  b 
Rest  =  [c] 

stored  inargs  =  [T6,b,c,b,c] 

deleting  b 

from  [T6,b,c,b,c] 

Tempi  =  [T6,c,b,c] 
checking  membership  of  b 
In  [T6,c,b,c] 
retracting  [T6,b,c,b,c] 
asserting  CT6,c,b,c] 

In  check.argsl 
X  =  c 
Rest  =  [] 

stored  inargs  =  CT6,c,b,c] 
deleting  c 
from  [T6,c,b,c] 

Tempi  =  CT6,b,c3 

checking  membership  of  c 

In  [T6,b,c3 

retracting  CT6,c,b,c3 

asserting  CT6,b,c3 

checking  inargs  CT6,b,c3 

retracting  CT3,Tl,T5,T2,as,T63 

asserting  all  Unmatched  args  [T6,as,T2,T5,Tl,T33 

Rest  =  [xor_gatG(b,c,T4)3 

Ans  =  □ 

Tempi  =  Cxor_gateCb,c,T4)3 
Temp2  =  [xor_gate(b,c,T4)3 


In  analyze  1  xor_gate(b,c,T4) 

Unmatched  args  =  CT6,as,T2,T5,Tl,T3] 

Finishing  up  in  analyze 
Acc  =  Cxor_gate(.b,c,T4)] 

Args In  =  [b,c] 

ArgsOut  =  [14] 

HInArgs  =  Cb,c] 

HOutArgs  =  [14] 

New Args  =  [b,c,T4] 

NewHead  =  fool(b,c,T4) 

asserting  fool(b,c,T4) :-[xor_gate(b,c,T4)] 

retracting  [T6,b,c] 

asserting  direction(fool(b,c,T4) ,[b,c] ,[T4])) 

Ans2  =  fool(b,c,T4) 

Rest  =  [] 

Ans  =  [fool(b,c,T4)] 

Tempi  =  [fool(b,c,T4)] 

Temp2  =  [halfadd(a,T4,s,co) ,fool(b,c,T4)] 

In  analyze  1  halfadd(a,T4,s,co) 

Unmatched  args  =  [T6,as,T2,T5,Tl ,T3] 

In  analyze  1  fool(b,c,T4) 

Unmatched  args  =  CT6,as,T2,T5,Tl ,T3] 

Finishing  up  in  analyze 

Acc  =  [fool(b,c,T4) ,halfadd(a,T4,s ,co)] 

Argsin  =  [a,T4,b,c] 

ArgsOut  =  [s,co,T4] 

HInArgs  =  [a,b,c] 

HOutArgs  =  [co,s] 

NewArgs  =  [a,b,c,co,s] 

NewHead  =  foo2(a,b,c,co,s) 

asserting  foo2(a,b,c,co,s) :-[fool(b,c,T4) ,halfadd(a,T4,s ,co)] 

retracting  [15 , T2 , T3 , as , a , T4 , b , c] 

asserting  direction(foo2(a,b,c,co,s) , [a,b,c] , [co,s])) 

Circuit  =foo2(a,b,c,co,s) 
yes 
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?-  listing(fool) . 
fool(b,c,'T4’) 

[xor_gate(b,c, ’T4’ )]  • 


yes 

?-  halt. 

A:\THESIS\CODE>exit 

Script  completed  Mon  Oct  14  13:24:33  1991 

/********************End  of  Test  Results********************/ 


The  before  and  after  circuit  diagrams  are  shown  in  Figures  C.l  and  C.2.  Note  that  the 
circuit  diagram  for  the  specialized  version  matches  the  definition  of  “foo2”  as  reported 
to  the  screen.  The  internally  defined  connections  denoted  by  a  “T”  designation  may 
change  during  ihe  algorithm’s  execution  however,  the  change  is  consistently  propagated 
throughout  the  circuit  in  order  *^0  preserve  the  correctness  of  the  interconnections.  Test! 
differs  from  Clocksin’s  test  example,  given  in  this  appendix  as  test  4,  in  that  the  carry 
output,  Co,  is  specified  as  being  used  at  the  uppermost  level  while  the  unused  output,  T5, 
remains  hidden  to  the  user. 
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Figure  C.l.  Circuit  schematic  for  test  1  before  specialization. 
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Figure  C.2.  Circuit  schematic  for  test  1  after  specialization. 
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C.2.2  Test  2  Code  and  Results 


!  **%:(:*****************♦  + 

/**  test2  results  **/ 

/**  Test  2  looks  at  a  circuit  which  has  a  hierarchical  **! 

!**  module  consisting  of  other  hierarchical  and  primitive  **/ 
/*■*  modules.  The  subordinate  hierarchical  module  does  not  **/ 
/**  have  any  unused  outputs  and  can  be  completely  eliminated.  **/ 

/****!(!****:(c;t!********test2  circuit  definition********************/ 


test2 

scan(circuit2(a,b,c,as,s,co)) . 

circuit2(A,B,C,As,S,Co) 
halfadd(B,C,Unusedl,Unused2) , 
halfadd(A,T3,S,Co) , 
xor_gate(A,As ,T3) . 

/**  The  following  submodule  definitions  will  be  needed  in  **/ 
/**  order  to  execute  test2.  Section  C.1.5  further  explains  **/ 
/**  the  code.  **/ 

halfadd(A,B,S,C) 
xor_gate(A,B,S) , 
nand_gate(A,B,T) , 
nnot_gate(T,C) . 


direcS’  Ji.  'halfadd(A,B,S,C)  ,  [A.B]  ,  [S,C3  )  . 
direccioi  (xor_gate(A,B.Out) , [A.B] ,  [Out] ) . 
direction(nnot_gate(A,B) , [A] , [B] ) . 
direction(nand_gate(A,B,C) ,  [A.B] , [C]) . 
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priinitive(xor_gate) . 
primitive(nand_gate) . 
primitive(nnot_gate) . 

/********;(t+*>(!**:(!********j(!'rest  Results************************/ 

Script  VI. 0  session  started  Mon  Oct  14  14:28:43  1991 

Microsoft(R)  MS-DOS(R)  Version  4.01 

(C)Copyright  Microsoft  Corp  1981-1988 

A : \THESIS\CODE>prolog 


I  MS-DOS  Prolog-1  Version  2.2  I 

I  Copyright  1983  Serial  number:  0001213  | 

I  Expert  Systems  Ltd.  I 

I  Oxford  U.K.  I 

+ - + 

?-  [speccode] . 
speccode  consulted 
?-  test2. 

HeadArgs  =Ca,b,c,as,s,co] 

Body  =halfadd(b,c,_102,_103) ,halfadd(a,_109,s,co) ,xor_gate(a,as ,_109) 
Goals  =[half addCb,c,_102,_103) ,halfadd(a,_109,s,co) ,xor_gate(a,as,_109)] 
GoalArgsIn  =Ca,as,a,_109,b,c] 

GoalArgsOut  =  [_ 109 , s , co , _ 102 , _ 103] 

Looking  at  _109 
Looking  at  s 
Looking  at  co 
Looking  at  _102 
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Looking  at  _103 
Unmatched  = [13,12] 
asserting  Ca,as,a,Tl,b,c] 

In  analyze  1  half add(b,c,T2,T3) 

Unmatched  args  =  [T3,T2] 

In  analyze  2  halfadd(b,c,T2,T3) 

Unmatched  args  =  [T3,T2] 

In  specialize  1  half add(b,c,T2,T3) 

In  specialize  2  halfadd(b,c,T2,T3) 

Pred  =  half add 

Goals  =  [xor_gate(b,c,T2) ,nand_gate(b,c,_368) ,nnot_gate(_368,T3)] 
Looking  at  T3 
Looking  at  _368 
Looking  at  T2 
Unmatched  =  [] 
looking  at  [T3,T2] 

asserting  the  following  Inargs  CT4,b,c,b,c] 
retracting  [T3,T2] 
asserting  [T2,T3] 

In  analyze  1  xor_gate(b,c,T2) 

Unmatched  args  =  [T2,T3] 

In  analyze  2  xor_gate(b,c,T2) 

Unmatched  args  =  [T2,T3] 

In  specialize  1  xor_gate(b,c,T2) 

Unmatched  args  =[T2,T3] 

In  check_argsl 
X  =  b 
Rest  =  [c] 

stored  inargs  =  [T4,b,c,b,c] 

deleting  b 

from  [T4,b,c,b,c] 

Tempi  =  [T4,c,b,c] 
checking  membership  of  b 
In  [T4,c,b,c] 
retracting  [T4,b,c,b,c3 
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asserting  [T4,c,b,c] 

In  check_argsl 
X  =  c 
Rest  =  [] 

stored  inargs  =  [T4,c,b,c] 
deleting  c 
from  CT4,c,b,c] 

Tempi  =  CT4,b,c] 
checking  membership  of  c 
In  CT4,b,c] 
retracting  [T4,c,b,c] 
asserting  CT4,b,c] 
checking  inargs  CT4,b,c] 
retracting  [T2,T3] 

asserting  all  Unmatched  args  [T3,T2] 

Rest  =  Cnand_gate(b,c,T4) ,nnot_gate(T4,T3)] 
Ans  =  □ 

Tempi  =  Cnand_gate(b,c,T4) ,nnot_gate(T4,T3)] 
Temp2  =  Cnand_gate(b,c,T4) ,nnot_gate(T4,T3)] 
In  cinalyze  1  nand_gate(b,c,T4) 

Unmatched  args  =  CT3,T2] 

In  analyze  1  nnot_gate(T4,T3) 

Unmatched  args  =  CT3,T2] 

In  analyze  2  nnot_gate(T4,T3) 

Unmatched  args  =  [T3,T2] 

In  specialize  1  nnot_gate(T4,T3) 

Unmatched  args  =CT3,T2] 

In  check_argsl 
X  =  T4 
Rest  =  [] 

stored  inargs  =  [T4,b,c] 
deleting  T4 
from  [T4,b,c3 
Tempi  =  Cb,c] 
in  check_args  2 
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adding  T4 
to  Acc  [] 

checking  inargs  CT4,b,c] 
retracting  [13,12] 

asserting  all  Unmatched  args  [T2,T3,T4] 
Rest  =  [] 

Ans  =  [] 

Tempi  =  [] 

Temp2  =  Cnand_gate(b ,c,T4)] 

In  analyze  1  nand_gate(b,c,T4) 
Unmatched  args  =  [T2,T3,T4] 

In  analyze  2  nand_gate(b,c,T4) 
Unmatched  args  =  [T2,T3,T4] 

In  specialize  1  nand_gate(b,c,T4) 
Unmatched  args  =[T2,T3,T4] 

In  check.argsl 
X  =  b 
Rest  =  [c] 

stored  inargs  =  CT4,b,c] 
deleting  b 
from  [T4,b,c] 

Tempi  =  [T4,c] 
in  check.args  2 
adding  b 
to  Acc  □ 

In  check_argsl 
X  =  c 
Rest  =  [] 

stored  inargs  =  [T4,b,c] 
deleting  c 
from  [T4,b,c] 

Tempi  =  [T4,b] 
in  check, args  2 
adding  c 
to  Acc  [b] 


checking  inargs  CT4,b,c] 
retracting  CT2,T3,T4] 

asserting  all  Unmatched  args  CT4,T3,T2,b,c] 

Rest  =  [] 

Ans  =  [] 

Tempi  =  [] 

Temp2  =  [] 

Finishing  up  in  analyze 
Acc  =  [] 

Args  In  =  [] 

ArgsOut  =  [] 

HInArgs  =  [] 

HOutArgs  =  □ 

NewArgs  =  [] 

NewHead  =  fool 
asserting  fool:-[] 
retracting  CT4,b,c] 
asserting  directionCfool, [] , [])) 

Ans2  =  fool 

Rest  =  [halfadd(a,Tl,s,co) ,xor_gate(a,as,Tl)] 

Ans  =  [fool] 

Tempi  =  [half add(a, Tl, s, co) ,xor_gate(a, as, Tl) , fool] 
Temp2  =  [half add(a, Tl, s, co) ,xor_gate(a, as, Tl) , fool] 
In  analyze  1  halfadd(a,Tl ,s,co) 

Unmatched  args  =  [T4,T3,T2,b,c] 

In  analyze  1  xor_gate(a,as ,T1) 

Unmatched  args  =  [T4,T3,T2,b,c] 

In  cinalyze  1  fool 

Unmatched  args  =  [T4,T3,T2,b,c] 

Finishing  up  in  analyze 

Acc  =  [fool,xor_gate(a,as,Tl) ,halfadd(a,Tl,s,co)] 
Argsin  =  [a,Tl,a,as] 

ArgsOut  =  [s,co,Tl] 

HInArgs  =  [a, as] 

HOutArgs  =  [co,s] 
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NewArgs  =  [a,as,co,s] 

NewHead  =  foo2(a,as ,co,s) 

asserting  foo2(a,as,co,s) :-[xor_gate(a,as,Tl) ,halfadd(a,Tl,s,co)] 
retracting  Ca,as,a,Tl,b,c] 

asserting  direct ion(f oo2(a, as ,co,s) , [a, as] , [co,s] )) 

Circuit  =foo2(a,as,co,s) 
yes 

?-  halt. 

A:\THESIS\CODE>exit 

Script  completed  Mon  Oct  14  14:29:41  1991 

/*!(c^***j)!*+********+*:)(:t;!t:**End  of  Tost  Rgsults******************/ 


The  before  and  after  circuit  diagrams  are  shown  in  Figures  C.3  and  C.4  respectively. 
Note  that  the  redundant  higher-level  module,  the  full-adder  was  successfully  removed. 
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Figure  C.3.  Circuit  schematic  for  test  2  before  specialization. 


Figure  C.'l.  Circuit  schemalir  for  tost  2  after  specialization. 
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C.2.3  Test  3  Code  and  Results 

/  )(c  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  :4c  ^  ^  ^  ^ ^  ^  / 

/**  tests  results  **/ 

/**  Test  3  inputs  a  circuit  where  every  output  is  used  and  **/ 
/**■  no  specialization  is  possible.  **/ 

/)(:***3)c***:(c*it:***!(c*-test3  citcuit  definition*********************/ 


tests  :- 

scan(circuit3(a,b,c,as,s,co)) . 

circuit3(A,B,C,As,S,Co)  :- 
halfadd(B,C,Tl,T2), 
halfadd(A,Ti,S,Co) , 
xor_gate(A,As,T3) , 
and_gate(Tl ,T3,T4) , 
or_gate(T2,T4,Co) . 

/**  The  following  submodule  definitions  are  necessary  to  **/ 
/**  run  test  3.  They  are  further  explained  in  section  C.1.5.**/ 


halfadd(A,B,S,C)  :- 
xor_gate(A,B,S) , 
nand_gate(A,B,T) , 
nnot_gate(T,C) . 

direction(halfadd(A,B,S,C) , CA,B] , [S,C] ) . 
direction(or.gate(A,B,Out) , [A.B] > [Out] ) . 
direction(xor_gate(A,BtOut) , CA,B] , [Out] ) . 
direct lon(and_gate(A,B, Out) , [A.B] , [Out] ) . 
direction(nnot_gate(A,B) , [A] , [B] ) . 
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direction(nand_gate(A,B,C) ,  [A.B]  ,  M)  . 


primitive (or_gate) . 
primitive (xor_gate) . 
primitive (and_gate) . 
primitive (nnot_gate) . 
primitive(nand_gate) . 

/ *****;(!***** j(!*j(c*  +  ****'rgst  Results************************/ 

Script  VI. 0  session  started  Hon  Oct  14  14:47:59  1991 

Microsoft(R)  HS-DOS(R)  Version  4.0i 

(C)Copyright  Microsoft  Corp  1981-1988 

A:\THESIS\CODE>Prolog 
Bad  command  or  file  name 

A:\THESIS\CODE>prolog 


+ - + 

I  MS-DOS  Prolog- 1  Version  2.2  | 

I  Copyright  1983  Serial  number:  0001213  I 
I  Expert  Systems  Ltd.  1 

1  Oxford  U.K.  i 

+ - + 

?-  [speccode] . 
speccode  consulted. 

?-  tests. 

HeadArgs  =Ca,b,c,as,s,co3 

Body  =halfadd(b,c,_102,_103) ,halfadd(a,_102,s,co) ,xor_gate(a,as ,_118) , 
and.gate (_ 102 , _ 1 18 , _ 125) , or.gate (_ 103 , _ 125 , co) 
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Goals  -[halfadd(b,c,_102,_103) ,halfadd(a,_102,s,co) ,xor_gate(a,as,_118) , 
and_gat e (_ 102 , _ 1 18 , _ 125) , or.gate (_ 103 , _ 125 , co)] 

GoalArgsIn  =C_103,_125,_102,_118,a,as,a,_102,b,c] 

Goal ArgsOut  = [co , _ 125 , _ 1 18 , s , co , _ 102 , _ 103] 

Looking  at  co 
Looking  at  _125 
Looking  at  _118 
Looking  at  s 
Looking  at  co 
Looking  at  _102 
Looking  at  _103 
Unmatched  =[] 

asserting  CT4,Tl,T3,T2,a,as,a,T3,b,c] 

In  analyze  1  halfadd(b,c,T3,T4) 

Unmatched  args  =  [] 

In  analyze  1  halfadd(a,T3,s ,co) 

Unmatched  args  =  [] 

In  analyze  1  xor_gate(a,as,T2) 

Unmatched  args  =  [] 

In  analyze  1  and_gate(T3,T2,Tl) 

Unmatched  args  =  C] 

In  analyze  1  or_gate(T4,Tl,co) 

Unmatched  args  =  [] 

Finishing  up  in  analyze 

Acc  =  Cor_gate(T4,Ti,co),and_gate(T3,T2,Tl),xor_gate(a,as,T2), 
halfadd(a,T3,s,co) ,halfadd(b,c,T3,T4) j 

Argsin  =  Cb,c,a,T3,a.as,T3,T2,T4,Tl3 
ArgsOut  =  CT3,T4,s,cc,T2,Tl,co] 

HInArgs  =  Cb,c,a,as3 
KOutArgs  =  Cco,s] 

NewArgs  =  Cb,c,a,as,co,s3 


r-io 


NewHead  =  fool(b,c,a,as ,co,s) 


asserting  fool(b,c,a,as,co,s) :-Cor_gate(T4,Tl,co) ,and_gate(T3,T2,Tl) , 
xor_gate(a, as ,T2) ,half add(a ,T3 , s ,co) .half add(b , c,T3 ,T4)] 

retracting  [T4,T1 ,T3,T2,a,as .a.To.b.c] 

asserting  direction(fool(b,c,a, as.co.s) , [b.c.a, as] , [co.s] ) ) 

Circuit  =fool(b,c,a,as,co,s) 
yes 

?-  halt. 

A:\THESIS\CODE>exit 

Script  completed  Hon  Oct  14  14:49:06  1991 

/****:(c**;(:******;t:*J(!:(t*****End  Of  TeSt  RfiSUitS******************/ 

Figure  C.5  shows  the  circuit  under  con.sideration. 
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C.2.4  Test  4  Code  and  Results 

/*:t;*****^c:J:  +  *)((*))t*:(c********:t:*:t:***  +  **%^Jf:;(:*****T****^****=(:+******^:;(t**Jt!:(t:t:/ 

/**  test4  results  **/ 

/**  Test  4  is  Clocksin’s  test  as  described  in  Chapter  6  **/ 

^  ^  ^  ^  ^  ^  ^  SfC  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  /fC  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  .fC  ^  ^  ^  ^  ^  ^  ^  ^  )fc  ^  ^  ^  ^  ^  7^  ^  ^  ^  ^  ^  ^  ^  j 

/^t**^!:t!**:(;****!(:*!t:+*'t;est4  circuit  definition**************************/ 

test4  :- 

scan(twobit(al ,bl ,a2,b2,c,as,sl ,s2)) . 

twobit(Al,Bl ,A2,B2,C,As,S1,S2)  :- 
addsub(Al,Bl,C,As,Sl,T) , 
addsub ( A2 , B2 , T , As , S2 , Unused) . 

/**  The  following  submodule  definitions  are  necessary  to  **/ 

/**  carry  out  test  4.  Section  C.1.5  further  explains  the  **/ 

/**  following  procedures.  **/ 


addsub(A,B,C,As,S,Co)  ;- 
halfadd(B,C,Tl,T2) , 
halfadd(A,Tl,S, Unused) , 
xor_gate(A,As,T3) , 
and_gate(Tl ,T3,T4) , 
or_gate(T2,T4,Co) . 


halfadd(A,B,S,C)  :- 
xor_gate(A,B,S) , 
nand_gate(A,B,T) , 
nnot_gate(T,C) . 
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direction(addsub(A,B,C,As,S,Co) ,  [A.B.C.As] , [S,Co] ) . 
direction(halfadd(A,B,S,C) ,  [A.B] , [S.C]) . 
direction(or_gate(A,B,Out) , [A.B] , [Out]  ) . 
direction(xor_gate(A,B.Out) , [A,B] , [Out]) . 
directioii(and_gate(A,B,Cut) ,  [A,B]  ,  [Out] ) . 
direction(nnot_gate(A,B) .  [A] ,  [B]) . 
direction(nand_gate(A,B,C) , [A,B] , [C]) . 

primitive (or_gate) . 
primitive (xor_gate) . 
primitive(and_gate) . 
primitive(nnot_gate) . 
primitive (nand_gate) . 

/!'.**)t(******:)!*!(i**:t!*!i!)(!***Xest  Rcsults* ***************** **=*=/ 

Script  VI. 0  session  started  Mon  Oct  14  15:04:07  1991 

Microsoft(R)  MS-DOS(R)  Version  4.01 

(C)Copyright  Microsoft  Corp  1981-1988 

A : \THESIS\CODE>prolog 


I  MS-DOS  Prolog- 1  Version  2.2  I 
I  Copyright  1983  Serial  number:  0001213  I 
I  Expert  Systems  Ltd.  I 
I  Oxford  U.K.  I 
+ - + 


?-  [speccode]  . 
speccode  consulted 


C-'M 


?-  test4. 

HeadArgs  =[al,bl,a2,b2,c,as,sl ,s2] 

Body  =addsub(al,bl,c,as,sl,_121) ,addsub(a2,b2,_121,as,s2,_131) 

Goals  =Caddsub(al ,bl ,c,as,sl,_121) ,addsub(a2,b2,_121 ,as,s2,_131)3 
GoalArgsIn  = [a2 ,b2 , _121 , as , al ,bl , c ,as] 

GoalArgsOut  =Cs2,_131 ,sl ,_121] 

Looking  at  s2 
Looking  at  _131 
Looking  at  si 
Looking  at  _121 
Unmatched  =[11] 

asserting  [a2 , b2 , T2 , as , al ,bl , c , as] 

In  analyze  1  addsub(al,bl,c,as,sl,T2) 

Unmatched  args  =  [Tl] 

In  analyze  1  addsub(a2,b2,T2,as ,s2,Tl) 

Unmatched  args  =  CTl] 

In  analyze  2  addsub(a2,b2,T2,as,s2,Tl) 

Unmatched  args  =  [Tl] 

In  specialize  1  addsub(a2,b2,T2,as ,s2,Tl) 

In  specialize  2  addsub(a2,b2,T2,as,s2,Tl) 

Pred  =  addsub 

Goals  =  D.  :add(b2,T2,_359,_360),halfadd(a2,_359,s2,_368), 
xor_gate(! 2  as ,_375) ,and_gate(_359,_375,_382) ,or_gate(_360,_382,Tl)] 

Looking  at  Tl 
Looking  at  _382 
Looking  at  _375 
Looking  at  s2 
Looking  at  _368 
Looking  at  _359 
Looking  at  _360 
Unmatched  =  [T5] 
looking  at  CTl] 

asserting  the  following  Inargs  CT7,T3,T6,T4,a2,as,a2,T6,b2,T2] 
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retracting  [Tl] 
asserting  [15,11] 

In  analyze  1  half add (b2,T2,T6,T7) 

Unmatched  args  =  [T5,T1] 

In  analyze  1  halfadd(a2,T6,s2,T5) 

Unmatched  args  =  [T5,T1] 

In  analyze  2  halfadd(a2,T6,s2,T5) 

Unmatched  args  =  [15,11] 

In  specialize  1  halfadd(a2,T6,s2,T5) 

In  specialize  2  halfadd(a2,T6,s2,T5) 

Pred  =  halfadd 

Goals  =  [xor_gate(a2,T6,s2) ,nand_gate(a2,T6,_801) ,nnot_gate(_801 ,T5)] 
Looking  at  T5 
Looking  at  _801 
Looking  at  s2 
Unmatched  =  [] 
looking  at  [T5,T1] 

asserting  the  following  Inargs  [T8,a2,T6,a2,T6] 
retracting  [T5,T1] 
asserting  [T1,T5] 

In  analyze  1  xor_gate(a2,T6,s2) 

Unmatched  args  =  [T1,T5] 

In  analyze  1  nand_gate(a2,T6,T8) 

Unmatched  args  =  [T1,T5] 

In  analyze  1  nnot_gate(T8,T5) 

Unmatched  args  =  [T1,T5] 

In  analyze  2  nnot_gate(T8,T5) 

Unmatched  args  =  [Tl,T5] 

In  specialize  1  nnot_gate(T8,T5) 

Unmatched  args  =[T1,T5] 

In  check_argsl 
X  =  T8 
Rest  =  [] 

stored  inargs  =  [T8,a2,T6,a2,T6] 
deleting  T8 
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from  CT8,a2,T6,a2,T6] 

Tempi  =  [a2,T6,a2,T6] 
in  check.args  2 
adding  T8 
to  Acc  □ 

checking  inargs  [T8,a2,T6,a2,T6] 
retracting  [T1,T5] 

asserting  all  Unmatched  args  CT5,T1,T8] 

Rest  =  [] 

Ans  =  [] 

Tempi  =  □ 

Temp2  =  [nand_gate(a2,T6,T8) ,xor_gate(a2,T6,s2)] 
In  analyze  1  nand_gate(a2,T6,T8) 

Unmatched  args  =  CT5,T1,T8] 

In  analyze  2  nand_gate(a2,T6,T8) 

Unmatched  args  =  CT5,T1,T8] 

In  specialize  1  nand_gate(a2,T6,T8) 

Unmatched  args  =CTS,T1,T8J 
In  check.argsl 
X  =  a2 
Rest  =  CT6] 

stored  inargs  =  CT8,a2,T6,a2,T6] 

deleting  a2 

from  CT8,a2,T6,a2,T6] 

Tempi  =  CT8,T6,a2,T6] 
checking  membership  of  a2 
In  CT8,T6,a2,T6] 
retracting  CT8,a2,T6,a2,T6] 
asserting  CT8,T6,a2,T6] 

In  check_argsl 
X  =  T6 
Rest  =  [] 

stored  inargs  =  CT8,r6,a2,T6] 

deleting  T6 

from  CT8,T6,a2,T63 


Tempi  =  CT8,a2,T6] 

checking  membership  of  T6 

In  CT8,a2,T6] 

retracting  CT8,T6,a2,T6] 

asserting  CT8,a2,T6] 

checking  inargs  [T8,a2,T6] 

retracting  CT5,T1,T8] 

asserting  all  Unmatched  args  [T8,T1,TS] 

Rest  =  Cxor_gate(a2,T6,s2)] 

Ans  =  [] 

Tempi  =  Cxor_gate(a2,T6,s2)] 

Temp2  =  Cxor_gate(a2,T6,s2)] 

In  analyze  1  xor_gate(a2,T6,s2) 

Unmatched  args  =  CT8,T1,T5] 

Finishing  up  in  analyze 
Acc  =  Cxor_gate(a2,T6,s2)3 
Args In  =  Ca2,T63 
ArgsOut  =  Cs2] 

HInArgs  =  Ca2,T6] 

HOutArgs  =  Cs2] 

NewArgs  =  Ca2,T6,s2] 

NewHead  =  fool(a2,T6,s2) 

asserting  fool(a2,T6,s2) :-[xor_gate(a2,T6,s2)] 
retracting  CT8,a2,T6] 

asserting  direction(foolCa2,T6,s2) , Ca2,T6] , [s2] )) 

Ans2  =  fool(a2,T6,s2) 

Rest  =  [xor_gate(a2,as,T4) ,and_gate(T6,T4,T3) ,or_gate(T7,T3,Tl)] 

Ans  =  [fool(a2,T6,s2)] 

Tempi  =  [xor_gate(a2,as,T4) ,and_gate(T6,T4,T3) ,or_gateCT7 ,T3,T1) , 
fool(a2,T6,s2)] 

Temp2  =  [half add (b2 , T2 , T6 , T7 ) , xor.gat e (a2 , as , T4 ) , and.gate (T6 , T4 , T3 )  , 
or_gate(T7,T3,Tl),fool(a2,T6,s2)] 

In  analyze  1  halfadd(b2,T2,T6,T7) 
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Unmatched  args  =  [T8,T1,T5] 

In  analyze  1  xor_gate(a2,as,T4) 

Unmatched  args  =  [T8,T1,T5] 

In  analyze  1  and_gate(T6,T4,T3) 

Unmatched  args  =  CT8,T1,T5] 

In  analyze  1  or_gate(T7,T3,Tl) 

Unmatched  args  =  CT8,T1,T5] 

In  analyze  2  or_gate(T7,T3,Tl) 

Unmatched  args  =  CT8,T1,T5] 

In  specialize  1  or_gate(T7,T3,Tl) 

Unmatched  args  =CT8,T1,T5] 

In  check_argsi 
X  =  T7 
Rest  =  [13] 

stored  inargs  =  CT7,T3,T6,T4,a2,as,a2,T6,b2,T23 
deleting  T7 

from  CT7,T3,T6,T4,a2,as,a2,T6,b2,T23 
Tempi  =  CT3,T6,T4,a2,as,a2,T6,b2,T2] 
in  check. args  2 
adding  T7 
to  Acc  [] 

In  check.argsl 
X  =  T3 
Rest  =  [] 

stored  inargs  =  CT7,T3,T6,T4,a2,as,a2,T6,b2,T23 
deleting  T3 

from  CT7 ,T3 ,T6 ,T4 , a2 , as , a2 ,T6 ,b2 ,T2] 

Tempi  =  CT7,T6,T4,a2,as,a2,T6,b2,T2] 
in  check. args  2 
adding  T3 
to  Acc  CT7] 

checking  inargs  CT7,T3,T6,T4,a2,as,a2,T6,b2,T2] 
retracting  [T8,Tl,T5j 

asserting  all  Unmatched  args  CT5,T1,T8,T7,T3] 
Rest  =  [fool(a2,T6,s2)] 
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Ans  =  [] 

Tempi  =  Cfool(a2,T6,s2)] 

Temp2  =  Cand_gate(T6,T4,T3) ,xor_gate(a2,as,T4) ,halfadd(b2,T2,T6,T7) , 
fool(a2,T6,s2)] 

In  analyze  1  and_gate(T6,T4,T3) 

Unmatched  args  =  CT5,T1,T8,T7,T3] 

In  analyze  2  and_gate(T6,T4,T3) 

Unmatched  args  =  [TS.Tl ,T8,T7,T3] 

In  specialize  1  and_gate(T6,T4,T3) 

Unmatched  :rgs  =CTS,Tl,T8,T7,T3] 

In  check. Pigsl 
X  =  T6 
Rest  =  CT4] 

stored  inargs  =  [T7,T3,T6,T4,a2,as,a2,T6,b2,T23 
deleting  T6 

from  CT7 , T3 , T6 ,T4 , a2 , as , a2 , T6 , b2 ,T23 
Tempi  =  CT7,T3,T4,a2.as,a2,T6,b2,T2] 
checking  membership  of  T6 
In  [T7,T3,T4,a2,as,a2,T6,b2,T2] 
retracting  [T7 , T3 , T6 , T4 , a2 , as , a2 , T6 , b2 , T2] 
assert ing  CT7  , T3  , T4  ,  a2 ,  as ,  a2 , T6  , b2 , T2] 

In  check.argsl 
X  =  T4 
Rest  =  □ 

stored  inargs  =  CT7,T3,T4,a2,as,a2.T6,b2,T2] 
deleting  T4 

f r om  CT7 , T3 , T4 , a2 , as , a2 , T6 , b2 , T23 
Tempi  =  CT7,T3,a2,as,a2,T6,b2,T2] 
in  check.args  2 
adding  T4 
to  Acc  □ 

checking  inargs  CT7,T3,T4,a2,as,a2,T6,b2,T2] 
retracting  [TS.Tl ,T8,T7,T33 
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asserting  all  Unmatched  args  [T3,T7,T8.T1 ,T5,T4] 

Rest  =  Cxor_gate(a2, as, T4) ,halfadd(b2, 12,16, T7) ,fool(a2,T6,s2)] 
Ans  =  [] 

Tempi  =  Cxor_gate(a2,as,T4) ,half add(b2,T2,T6,T7) ,fool(a2,T6,s2)] 
Temp2  =  [xor_gate(a2,as,T4) , half add (b2,T2,T6,T7) ,fool(a2,T6,s2)] 
In  analyze  1  xor_gate(a2,as,T4) 

Unmatched  args  =  CT3,T7,T8,T1,T5,T4] 

In  analyze  2  xor_gate(a2,as,T4) 

Unmatched  args  =  [T3,T7,T8,T1 ,TS,T43 
In  specialize  1  xor_gate(a2,as ,T4) 

Unmatched  args  =CT3,T7,T8  T1,TS,T4] 

In  check. args 1 
X  =  a2 
Rest  =  [as] 

stored  inargs  =  [T7,T3,T4,a2,as,a2,T6,b2,T2] 
deleting  a2 

from  CT7,T3,T4,a^,as,a2,T6,b2,T2] 

Tempi  =  [T7,T3,T4,as,a2,T6,b2,T23 
checking  membership  of  a2 
In  CT7,T3,T4,as,a2,T6,b2,T2] 
retracting  [T7 , T3 , T4 , a2 , as , a2 , T6 , b2 , T2] 
ass< r’  g  [T7,T3,T4,as,a2,T6,b2,T23 
In  check. args 1 
X  =  as 
Rest  =  [] 

stored  inargs  =  CT7,T3,T4,as,a2,T6,b2,T23 
deleting  as 

from  [T7,T3,T4,as,a2,T6,b2,T23 
Tempi  =  CT7,T3,T4,a2,T6,b2,T23 
in  check.args  2 
adding  as 
to  Acc  □ 

checking  inargs  CT7,T3,T4,as,a2,T6,b2,T23 
retracting  [T3,T7,T8,T1,T5,T43 

asserting  all  Unmatched  args  CT4,T5,Tl,T8,T7,T3,as] 
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Rest  =  Chalfadd(b2,T2,T6,T7),fool(a2,T6,s2)] 

Ans  =  [] 

Tempi  =  Chalfadd(b2,T2,T6,T7),fool(a2,T6,s2)3 
Temp2  =  Chalfadd(b2,T2,T6,T7) ,fool(a2,T6,s2)] 

In  analyze  1  half add (b2,T2,T6,T7) 

Unmatched  args  =  CT4,T5,Tl,T8,T7,T3,as] 

In  analyze  2  half add (b2,T2,T6,T7) 

Unmatched  args  =  [T4,TS,Tl,T8.T7,T3,as3 
In  specialize  1  halfadd(b2,T2,T6,T7) 

In  specialize  2  halfadd(b2,T2,T6.T7) 

Pred  =  half add 

Goals  =  [xor_gate(b2,T2.T6) ,nand_gate(b2,T2,_2022) ,nnot_gate(_2022,T7)] 
Looking  at  T7 
Looking  at  .2022 
Looking  at  T6 
Unmatched  =  [] 

looking  at  CT4,T5,Tl,T8,T7,T3,as] 
asserting  the  following  Inargs  CT9,b2,T2,b2,T2] 
retracting  [14 ,T5 ,T1 ,T8 ,T7 ,T3 , as] 
asserting  [as,T3,T7,T8,Tl,T5,T4] 

In  analyze  1  xor_gate(b2,T2,T6) 

Unmatched  args  =  [as,T3,T7,T8,Tl,T5,T4] 

In  analyze  1  nand_gate(b2,T2,T9) 

Unmatched  args  =  [as,T3,T7,T8,Tl,T5,T4] 

In  analyze  1  nnot_gate(T9,T7) 

Unmatched  args  =  Cas,T3,T7,T8,Tl,T5,T4] 

In  analyze  2  nnot_gate(T9,T7) 

Unmatched  args  =  [as,T3,T7,T8,Tl,T5,T4] 

In  specialize  1  nnot_gate(T9,T7) 

Unmatched  args  =Cas,T3,T7.T8,Tl,T5,T4] 

In  check.argsl 
X  =  T9 
Rest  =  [] 

stored  inargs  =  [T9,b2,T2,b2,T2] 
deleting  T9 


from  CT9,b2,T2,b2,T2] 

Tempi  =  Cb2,T2,b2,T2] 
in  check_args  2 
adding  T9 
to  Acc  [] 

checking  inargs  CT9,b2,T2,b2,T2] 
retracting  [as , T3 , T7 , T8 , T 1 , T5 , T4] 

asserting  all  Unmatched  args  CT4,T5,Tl,T8,i7,T3,as,T9] 
Rest  =  □ 

Ans  =  [] 

Tempi  =  G 

Temp2  =  [nand_gate(b2,T2,T9) ,xor_gate(b2,T2,T6)] 

In  analyze  1  nand_gate(b2,T2,T9) 

Unmatched  args  =  CT4,T5,Tl,T8,T7,T3,as,T9] 

In  analyze  2  nand_gate(b2,T2,T9) 

Unmatched  args  =  CT4,TS,Tl,T8,T7,T3,as,T9] 

In  specialize  1  nand_gate(b2,T2,T9) 

Unmatched  args  =CT4,TS,Tl,T8,T7,T3,as,T93 
In  check_argsl 
X  =  b2 
Rest  =  CT2] 

stored  inargs  =  CT9,b2,T2,b2,T2] 

deleting  b2 

from  CT9,b2,T2,b2,T2] 

Tempi  =  CT9,T2,b2,T23 
checking  membership  of  b2 
In  CT9,T2,b2,T23 
retracting  CT9,b2,T2,b2,T23 
asserting  [T9,T2,b2,T23 
In  check_argsl 
X  =  T2 
Rest  =  [3 

stored  inargs  =  CT9,T2,b2,T23 

deleting  T2 

from  [T9,T2,b2,T23 
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Tempi  =  CT9,b2,T2] 

checking  membership  of  T2 

In  CT9,b2,T2] 

retracting  CT9,T2,b2,T2] 

asserting  [T9,b2,T2] 

checking  inargs  [T9,b2,T2] 

retracting  [14 ,T5 ,T1 ,T8 ,T7 ,T3 , as ,T9] 

asserting  all  Unmatched  args  [T3,as,T3,T7,T8,Ti,TS,T43 

Rest  =  [xor_gate(b2,T2,T6)3 

Ans  =  [] 

Tempi  =  [xor_gate(b2,T2,T6)] 

Temp2  =  [xor_gate(b2,T2,T6)] 

In  analyze  1  xor_gate(b2,T2,T6) 

Unmatched  args  =  CT9,as,T3,T7,T8jTl,T5.T43 

Finishing  up  in  analyze 

Acc  =  [xor_gate(b2,T2,T6)3 

Args In  =  [b2,T23 

ArgsOut  =  CT63 

HInArgs  =  Cb2,T23 

KOutArgs  =  CT63 

Nefc-Args  =  [b2,T2,T63 

MewHead  =  foo2(b2,T2,T6) 

asserting  foo2(b2,T2,T6) [xor_gate(b2,T2,T6)3 
retracting  [T9,b2,T23 

asserting  direction(foo2(b2,T2,T6) , [b2,T23 , CT63)) 

Ans2  =  foo2(b2,T2,T6) 

Rest  =  [fool(a2,T6,s2)3 

Ans  =  Cfoo2(b2.T2,T6)3 

Tempi  =  [fool(a2,T6,s2) ,foo2(b2,T2,T6)3 

Temp2  =  [fool(a2,T6,s2) ,foo2(b2,T2,T6)3 

In  analyze  1  fool(a2,T6,s2) 

Unmatched  args  =  CT9,as,T3,T7,T8,Tl ,75,T43 
In  analyze  1  foo2(b2,T2,T6) 

Unmatched  args  =  [T9,as,T3,T7,T8,Tl ,T5,T43 
Finishing  up  in  analyze 


Acc  =  [foo2(b2,T2,T6),fool(a2,T6,s2)] 

Argsin  =  [a2,T6,b2,T2] 

ArgsOut  =  [s2,T6] 

HInArgs  =  Ca2,b2,T2] 

HOutArgs  =  [s2] 

NewArgs  =  Ca2,b2,T2,s2] 

NewHead  =  foo3(a2,b2,T2,s2) 

asserting  foo3(a2,b2,T2,s2) Cfoo2(b2,T2,T6) ,fool(a2,T6,s2)] 
retracting  CT7 ,T3 ,T4 , as , a2 ,T6 ,b2 ,T2] 

asserting  direction(foo3(a2,b2,T2,s2) , [a2,b2,T2] , [s2])) 

Ans2  =  foo3(a2,b2,T2,s2) 

Rest  =  [] 

Ans  =  [foo3(a2,b2,T2,s2)] 

Tempi  =  [foo3(a2,b2,T2,s2)] 

Temp2  =  [addsub(al ,bl ,c,as ,sl ,T2) ,foo3(a2,b2,T2,s2)] 

In  analyze  1  addsub(al,bl,c,as,sl,T2) 

Unmatched  args  =  CT9,as,T3,T7,T8,Tl,T5,T43 
In  analyze  1  foo3(a2,b2,T2,s2) 

Unmatched  args  =  CT9,as,T3,T7,T8,Tl,T5,T4] 

Finishing  up  in  analyze 

Acc  =  [foo3(a2,b2,T2,s2) ,addsub(al,bl,c,as,sl,T2)] 

Argsin  =  [al,bl,c,as,a2,b2,T2] 

ArgsOut  =  Csl,T2,s2] 

HInArgs  =  [al,bl,c,as,a2,b2] 

HOutArgs  =  Cs2,sl] 

NewArgs  =  Cal,bl,c,as,a2,b2,s2,sl] 

NewHead  =  foo4(al ,bl ,c,as ,a2,b2,s2,sl) 

asserting  foo4(al,bl,c,as,a2,b2,s2,sl) :-Cfoo3(a2,b2,T2,s2) , 
addsub(al ,bl ,c,as ,sl ,T2)] 

retracting  Ca2 , b2 , T2 , as , a 1 , b 1 , c , as] 

asserting  direct ion (foo4(al ,bl ,c,as ,a2 ,b2 ,s2,si) , 
[al,bl,c,as,a2,b2] , [s2,sl])) 
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Circuit  =foo4(al ,bl ,c ,as,a2,b2,s2,sl) 
yes 

?-  listing(foo3) . 
foo3(a2,b2,’T2’ ,s2) 

Cfoo2(b2,  ’T2’ ,  ’T60  ,fool(a2,  ’T6’  ,s2)]  . 


yes 

?-  listing(foo2) . 
foo2(b2,’T2’ ,’T6') 

[xor_gate(b2,'T2' ,’T6')]  . 


yes 

?-  listing(fool) . 
fbol(a2,’T6’ ,s2) 

Cxor_gate(a2, ’T6’ ,s2)]  . 


yes 

?-  halt. 

A:\THESIS\CODE>exit 

Script  completed  Hon  Oct  14  15:05:44  1991 
/******:t:;t:***!(t***:)!***>i<End  of  Tost  Results********************/ 


The  before  and  after  circuit  diagrams  are  shown  in  Chapter  6.  Note  that  the  built 
in  predicate  listing(X)  was  used  to  show  the  composition  of  modules  which  have  been 
specialized. 
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